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
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
网络漫游的eduroam体系结构
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.
本文档描述了学术界用于联邦（无线）网络访问的eduroam服务的体系结构。IEEE802.1X、可扩展身份验证协议（EAP）和eduroam中使用的RADIUS的组合为漫游网络访问提供了安全、可扩展和可部署的服务。在过去十年中，教育部门成功地部署了eduroam，这可能为其他部门提供了一个范例，因此本文件。特别地，描述了最初的体系结构选择和标准选择，以及由操作经验引起的更改。
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.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7593.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Notational Conventions . . . . . . . . . . . . . . . . . 4
1.3. Design Goals . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Solutions That Were Considered . . . . . . . . . . . . . 5
2. Classic Architecture . . . . . . . . . . . . . . . . . . . . 6
2.1. Authentication . . . . . . . . . . . . . . . . . . . . . 6
2.1.1. IEEE 802.1X . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. EAP . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Federation Trust Fabric . . . . . . . . . . . . . . . . . 8
2.2.1. RADIUS . . . . . . . . . . . . . . . . . . . . . . . 9
3. Issues with Initial Trust Fabric . . . . . . . . . . . . . . 11
3.1. Server Failure Handling . . . . . . . . . . . . . . . . . 12
3.2. No Signaling of Error Conditions . . . . . . . . . . . . 13
3.3. Routing Table Complexity . . . . . . . . . . . . . . . . 14
3.4. UDP Issues . . . . . . . . . . . . . . . . . . . . . . . 15
3.5. Insufficient Payload Encryption and EAP Server Validation 16
4. New Trust Fabric . . . . . . . . . . . . . . . . . . . . . . 17
4.1. RADIUS with TLS . . . . . . . . . . . . . . . . . . . . . 18
4.2. Dynamic Discovery . . . . . . . . . . . . . . . . . . . . 19
4.2.1. Discovery of Responsible Server . . . . . . . . . . . 19
4.2.2. Verifying Server Authorization . . . . . . . . . . . 20
4.2.3. Operational Experience . . . . . . . . . . . . . . . 21
4.2.4. Possible Alternatives . . . . . . . . . . . . . . . . 21
5. Abuse Prevention and Incident Handling . . . . . . . . . . . 22
5.1. Incident Handling . . . . . . . . . . . . . . . . . . . . 22
5.1.1. Blocking Users on the SP Side . . . . . . . . . . . . 23
5.1.2. Blocking Users on the IdP Side . . . . . . . . . . . 24
5.1.3. Communicating Account Blocking to the End User . . . 25
5.2. Operator Name . . . . . . . . . . . . . . . . . . . . . . 26
5.3. Chargeable User Identity . . . . . . . . . . . . . . . . 27
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28
6.1. Collusion of Service Providers . . . . . . . . . . . . . 28
6.2. Exposing User Credentials . . . . . . . . . . . . . . . . 28
6.3. Track Location of Users . . . . . . . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7.1. Man-in-the-Middle and Tunneling Attacks . . . . . . . . . 29
7.1.1. Verification of Server Name Not Supported . . . . . . 29
7.1.2. Neither Specification of CA nor Server Name Checks
during Bootstrap . . . . . . . . . . . . . . . . . . 29
7.1.3. User Does Not Configure CA or Server Name Checks . . 30
7.1.4. Tunneling Authentication Traffic to Obfuscate User
Origin . . . . . . . . . . . . . . . . . . . . . . . 30
7.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 31
7.2.1. Intentional DoS by Malign Individuals . . . . . . . . 31
7.2.2. DoS as a Side-Effect of Expired Credentials . . . . . 32
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1. Normative References . . . . . . . . . . . . . . . . . . 33
8.2. Informative References . . . . . . . . . . . . . . . . . 34
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
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
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.
2002年，欧洲研究和教育共同体开始为学术界的学生和员工创建网络漫游服务[eduroam start]。10多年后的今天，这项服务已发展到10000多个服务地点，为除南极洲以外的所有大陆的数百万用户提供服务。
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.
本备忘录旨在解释eduroam设计的考虑因素，并记录操作经验和导致IETF规范（如TCP上的RADIUS[RFC6613]和TLS上的RADIUS[RFC6614]）的变更，以及促进RADIUS的替代用途，如用于web以外联合访问的应用程序桥接（ABFAB）[ABFAB-ARCH]。虽然eduroam服务仅限于学术界，但eduroam体系结构可以轻松地在其他环境中重用。
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.
首先，本备忘录描述了eduroam[eduroam主页]的原始架构。然后，当eduroam获得大规模部署时，出现了一些操作问题。最后，讨论了减轻上述问题的eduroam体系结构的增强。
This document uses identity management and privacy terminology from [RFC6973]. In particular, this document uses the terms "Identity Provider", "Service Provider", and "identity management".
本文件使用[RFC6973]中的身份管理和隐私术语。特别是，本文件使用了术语“身份提供商”、“服务提供商”和“身份管理”。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Note: Also, the policy to which eduroam participants subscribe expresses the requirements for participation in RFC 2119 language.
注：此外，eduroam参与者签署的政策表达了参与RFC 2119语言的要求。
The guiding design considerations for eduroam were as follows:
eduroam的指导设计考虑如下：
- 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).
接入服务提供商（SP）需要能够确定用户是否有权使用网络资源。此外，在资源被滥用的情况下，需要能够唯一地识别用户（与用户的身份提供者（IdP）运营商合作）。
- 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.
注意：来宾用户和普通用户之间的流量分离是可能的（例如，通过使用VLAN），并且在eduroam中得到了广泛的应用。
- 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.
所创建的基础设施应该扩展到大量用户和组织，而不需要大量的协调和其他管理过程（可能除了初始设置）。具体来说，访问另一个组织的用户不必经历管理过程。
- 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.
组织和用户都应该很容易参与漫游基础设施；否则，它可能会阻碍广泛采用。特别是，不应该安装客户端（或者应该很容易），而应该只进行一次性配置。
- 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.
一个重要的设计标准是，最终用户与其身份提供者之间需要存在安全关联，从而消除凭证被盗的可能性。eduroam政策中规定了最低安全要求，并可能随时间变化。作为防止用户错误和疏忽的额外保护，参与身份提供商应该可以添加自己对自己用户身份验证质量的要求，而不需要整个基础设施来实现相同的要求。
- 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.
系统的设计应提供用户匿名化，即对包括服务提供商在内的任何第三方隐藏用户身份的可能性。
- 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.
在一个有数千个组织参与的基础设施中，显然应该可以使用来自不同供应商的设备；因此，使用开放标准构建基础设施非常重要。
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].
试验了三种体系结构：一种基于VPN技术（视为安全但不可扩展），一种基于Web捕获门户（可扩展但不安全），另一种基于IEEE 802.1X，后者是现在eduroam体系结构的基础。有关候选体系结构及其相对优点的概述，请参见[NRNROAMING select]。
The chosen architecture is based on:
选择的体系结构基于：
o IEEE 802.1X [IEEE.802.1X] as the port-based authentication framework using
o IEEE 802.1X[IEEE.802.1X]作为基于端口的身份验证框架，使用
o EAP [RFC3748] for integrity-protected and confidential transport of credentials and
o EAP[RFC3748]用于凭证和文件的完整性保护和机密传输
o a RADIUS [RFC2865] hierarchy as the trust fabric.
o RADIUS[RFC2865]层次结构作为信任结构。
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.
像eduroam这样的联盟基本上实现了两种类型的直接信任关系（和一种间接信任关系）。最终用户和IdP（由用户的家庭组织操作）之间以及IdP和SP（在eduroam中，访问位置的网络运营商）之间的信任关系。在eduroam中，用户和IdP之间的信任关系是通过相互认证实现的。IDP和SP通过使用RADIUS层次结构建立信任。
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.
这两种形式的信任关系依次提供了可传递的信任关系，使SP信任用户使用其网络资源。
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).
eduroam中的身份验证是通过使用IEEE 802.1X[IEEE.802.1X]和EAP[RFC4372]的组合来实现的（后者通过RADIUS进行来宾访问；参见第2.2节）。
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).
通过使用IEEE 802.1X[IEEE.802.1X]框架进行基于端口的网络身份验证，为访问（和本地）eduroam用户提供网络访问（SPs）的组织可以确保只有授权用户才能访问。用户（或者更确切地说，用户的请求者）向SP处的身份验证者（Wi-Fi接入点或交换机）发送访问请求，身份验证者将访问请求转发给SP的身份验证服务器，该身份验证服务器反过来通过RADIUS层次结构将请求代理给用户的家庭组织（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.
注意：本地无线基础设施和本地RADIUS服务器之间连接的安全性是每个SP本地网络的一部分；因此，它超出了本文件的范围。为完整起见，应说明接入点及其控制器之间的安全性取决于供应商，控制器（或独立接入点）和本地RADIUS服务器之间的安全性基于典型的RADIUS共享秘密机制。
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.
为了让用户知道eduroam服务的可用性，提供无线网络访问的SP必须广播服务集标识符（SSID）“eduroam”，除非该标识符与另一个eduroam SP的SSID冲突，在这种情况下，可以使用以“eduroam-”开头的SSID。后者的缺点是客户端不会自动连接到该SSID，从而失去无缝连接体验。
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.
注：普通eduroam SSID的直接含义是用户无法区分与家庭网络的连接和另一eduroam机构的来宾网络（IEEE 802.11-2012确实有所谓的“互通”来进行区分，但尚未广泛实施）。此外，如果没有适当的服务器验证，用户甚至可能被欺骗加入流氓eduroam网络。因此，应让用户意识到，他们不应承担eduroam基础设施中的数据机密性。
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.
为了保护用户数据的空中机密性，eduroam SP的IEEE 802.11无线网络必须部署WPA2+AES，并且它们还可以使用临时密钥完整性协议（WPA/TKIP）支持受Wi-Fi保护的访问，作为对传统硬件用户的礼遇。
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].
可扩展身份验证协议（EAP）[RFC4372]的使用有两个目的。首先，正确选择的EAP方法允许将用户凭证的完整性保护和机密传输到主组织。其次，通过让所有RADIUS服务器透明地代理访问请求，无论RADIUS数据包中的EAP方法如何，EAP方法的选择是在用户的“主”组织和用户之间进行的。换句话说，原则上，EAP中可携带的每种身份验证形式都可以在eduroam中使用，只要它们符合eduroam策略服务定义[eduroam服务定义]中规定的最低要求。
+-----+
/ \
/ \
/ \
/ \
,----------\ | | ,---------\
| SP | | eduroam | | IdP |
| +----+ trust fabric +---+ |
`------+---' | | '-----+---'
| | | |
| \ / |
| \ / |
| \ / |
| \ / |
+----+ +-----+ +----+
| |
| |
+---+--+ +--+---+
| | | |
+-+------+-+ ___________________________ | |
| | O__________________________ ) +------+
+----------+
Host (supplicant) EAP tunnel Authentication server
+-----+
/ \
/ \
/ \
/ \
,----------\ | | ,---------\
| SP | | eduroam | | IdP |
| +----+ trust fabric +---+ |
`------+---' | | '-----+---'
| | | |
| \ / |
| \ / |
| \ / |
| \ / |
+----+ +-----+ +----+
| |
| |
+---+--+ +--+---+
| | | |
+-+------+-+ ___________________________ | |
| | O__________________________ ) +------+
+----------+
Host (supplicant) EAP tunnel Authentication server
Figure 1: Tunneled EAP
图1：隧道式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.
访问请求的代理基于EAP消息中的外部标识。根据[RFC7542]，这些外部标识必须是具有强制域的有效用户标识符，即something@realm或者只是@realm，其中realm部分是IdP所属机构的域名。为了保留凭证保护，参与组织必须部署提供相互身份验证的EAP方法。对于支持外部标识的EAP方法，建议使用匿名外部标识。eduroam中最常用的是所谓的隧道式EAP方法，该方法首先创建一个经过服务器验证的TLS[RFC5246]隧道，通过该隧道传输用户凭据。如图1所示，隧道EAP方法的使用在请求者和身份验证服务器之间创建了一个直接的逻辑连接，即使实际流量流经RADIUS层次结构。
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.
eduroam联合信任结构基于RADIUS。RADIUS信任基于RADIUS对等方之间的共享秘密。在eduroam中，任何源自受信任对等方的RADIUS消息都被隐式假定为源自漫游联盟的成员。
Note: See also the security considerations for a discussion on RADIUS security that motivated the work on RADIUS with TLS [RFC6614].
注：关于RADIUS安全性的讨论，请参见安全注意事项，该讨论推动了RADIUS与TLS的合作[RFC6614]。
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.
eduroam信任结构由RADIUS服务器（组织、国家、全球）的代理层次结构组成，该层次结构松散地基于DNS层次结构。也就是说，通常组织的RADIUS服务器与国家服务器就共享机密达成一致，而国家服务器又与根服务器就共享机密达成一致。访问请求通过RADIUS代理链路由到用户的身份提供者，并且访问接受（或拒绝）遵循相同的路径返回。
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.
注意：在某些情况下，RADIUS服务器的级别更高（例如，区域或大陆服务器），但这不会改变通用模型。此外，下面描述的分组交换实际上需要多次往返。
+-------+
| |
| . |
| |
+---+---+
/ | \
+----------------/ | \---------------------+
| | |
| | |
| | |
+--+---+ +--+--+ +----+---+
| | | | | |
| .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
+-------+
| |
| . |
| |
+---+---+
/ | \
+----------------/ | \---------------------+
| | |
| | |
| | |
+--+---+ +--+--+ +----+---+
| | | | | |
| .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
图2:eduroam半径层次结构
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:
将访问请求路由到家庭IdP是基于外部身份的领域部分完成的。例如（如图2所示），当用户paul@surfnet.nlSurfNET（SurfNET.NL）试图在诺克斯维尔田纳西大学（UTK.EDU）获得无线网络接入，以下情况发生：
o Paul's supplicant transmits an EAP access request to the Access Point (Authenticator) at UTK with outer identity of anonymous@surfnet.nl.
o Paul的请求者将EAP访问请求发送到UTK的接入点（验证器），外部标识为anonymous@surfnet.nl.
o The Access Point forwards the EAP message to its Authentication Server (the UTK RADIUS server).
o 接入点将EAP消息转发到其身份验证服务器（UTK RADIUS服务器）。
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 UTK RADIUS服务器检查该领域是否为本地领域；因为它不是，所以请求被代理到.edu RADIUS服务器。
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 .edu RADIUS服务器验证域；因为它不在.edu子域中，所以它将请求代理给根服务器。
o The root RADIUS server proxies the request to the .nl RADIUS server, since the ".nl" domain is known to the root server.
o 根RADIUS服务器将请求代理给.nl RADIUS服务器，因为根服务器知道“.nl”域。
o The .nl RADIUS server proxies the request to the surfnet.nl server, since it knows the SURFnet server.
o .nl RADIUS服务器将请求代理给surfnet.nl服务器，因为它知道surfnet服务器。
o The surfnet.nl RADIUS server decapsulates the EAP message and verifies the user credentials, since the user is known to SURFnet.
o surfnet.nl RADIUS服务器解除EAP消息的封装并验证用户凭据，因为用户是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 surfnet.nl RADIUS服务器通过RADIUS层次结构以相反顺序代理验证请求的结果（访问接受或访问拒绝），将验证请求的结果通知utk.edu服务器。
o The UTK RADIUS server instructs the UTK Access Point to either accept or reject access based on the outcome of the authentication.
o UTK RADIUS服务器根据身份验证的结果指示UTK访问点接受或拒绝访问。
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.
注意：根RADIUS服务器的描述是一种简化。实际上，根服务器分布在三大洲，每个洲都维护一个特定根服务器负责的顶级领域列表。这也意味着，对于洲际漫游，从一个根服务器到另一个根服务器还有一个额外的代理步骤。此外，节点的物理分布不需要镜像节点的逻辑分布。这有助于提高稳定性和可扩展性。
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.
虽然上一节中描述的分层RADIUS体系结构在整整十年中一直是eduroam操作的基础，但认证的指数级增长预计会导致聚合代理上的性能和操作瓶颈，事实上在某些情况下已经导致了这一瓶颈。以下各节描述了一些缺点以及由此产生的补救措施。
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).
在eduroam中，漫游用户的身份验证请求通过预配置的代理静态路由。代理的数量各不相同：在国家漫游情况下，代理的数量通常为1或2（一些国家部署了区域代理，这些代理又由国家代理汇总）；在国际漫游中，通常涉及3台或4台代理服务器（某些路由上的代理服务器数量可能更高）。
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:
RFC 2865[RFC2865]未定义故障转移算法。特别是，服务器的故障需要从没有应答推断出来。运营经验表明，这会对基础设施和最终用户体验产生不利影响：
1. Authentication failure: the first user whose authentication path is along a newly failed server will experience a long delay and possibly timeout
1. 身份验证失败：其身份验证路径位于新出现故障的服务器上的第一个用户将经历长时间延迟，可能会超时
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.
2. 错误推断的状态：由于代理链长于一个跃点，身份验证路径中的故障与下一个跃点中的故障无法区分。
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].
3. 无法确定服务器的恢复：只有发送到被认为不可操作的服务器的“实时”身份验证请求才能发现服务器再次处于工作状态。此问题已通过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.
在最坏的情况下，第二点可能会对系统的运行状态产生重大影响：想象一个领域的家庭服务器无法运行。来自该领域的用户试图在国际上漫游并尝试进行身份验证。热点位置上的RADIUS服务器可能会假定其自己的国家代理已关闭，因为它没有应答。该国家服务器完全处于活动状态，然后会假定国际聚合代理已关闭，这反过来又会认为母国代理国家服务器已关闭。这些假设都不是真的。更糟糕的是：在故障切换到备份的下一跳RADIUS服务器的情况下，该服务器也将被标记为已停用，因为通过该服务器也不会从已停用的主服务器收到任何回复。在短时间内，所有冗余聚合代理可能会被其前一跳视为失效。
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
在缺乏正确的下一跳状态派生的情况下，eduroam参与者引入了一些有趣的概念——最值得注意的是一种故障切换逻辑，它考虑的是每个领域的上/下状态，而不是每个下一跳RADIUS对等方的上/下状态（有关详细信息，请参阅[死领域]）。最近，RFC 5997[RFC5997]和
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.
只要每个跃点都实现RFC 5997，谨慎的故障切换参数就不太可能出现错误的“停机”。在这种情况下，死域检测主要用于防止大量请求代理到已知的死域。
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:
RADIUS协议缺少错误条件的信令，IEEE 802.1X标准不允许向最终用户的设备传输扩展故障原因。对于eduroam，这会产生两个问题：
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:
o 家庭服务器可能存在操作问题，例如，其身份验证决策可能取决于外部数据源，如SQL server或Microsoft的Active Directory，并且外部数据源不可用。如果RADIUS接口仍能正常工作，则有两个选项可用于答复由于此类错误情况而无法提供服务的访问请求：
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.
1. 不回复：无法得出结论可以通过不回复请求来解决。这种方法的好处是，最终用户的软件不会得出错误的结论，也不会给出诸如“也许你的密码错了”之类的无用提示。缺点是中间代理可能会得出错误的结论，因为它们的下游RADIUS服务器没有响应。
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.
2. 用拒绝回复：在此选项中，无法得出结论被视为身份验证失败。这种方法的优点是，中间代理对其RADIUS对等方的可达性状态保持正确的看法。缺点是，终端用户设备上的EAP请求者通常会给出错误的建议（“您的密码错误”），甚至触发永久性配置更改（例如，Windows内置请求者将从其注册表中删除凭据集，在下次连接尝试时提示用户输入密码）。Windows的后一种情况是重要的帮助台活动的来源；用户可能在最初存储密码后忘记了密码，但突然再次出现提示。
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.
eduroam社区和IETF RADEXT工作组已经就两种方法中的哪一种更合适进行了大量讨论，但没有得出结论。
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
当中间代理未收到下游RADIUS服务器的回复时，也需要考虑类似的问题。代理可以选择不回复原始请求，从而导致
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.
重试及其上游同行对其自身可用性得出错误结论；或者，它可能决定使用accessreject进行回复，以表明其自身的活跃性，但也会对最终用户产生影响。
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.
只有在下游服务器没有应答（或很久没有联系，因此其以前的工作状态过时）的情况下，才可以发送状态服务器监视程序请求。TCP连接的主动链路状态监控，例如RADIUS/TLS（见第4.1节），可以更清楚地指示是否存在活动的RADIUS对等方，但它不能解决已失效的后端问题。在RADIUS级别（用于其他RADIUS对等信息）和EAP级别（用于最终用户请求者信息）上发送错误回复的显式功能可以缓解这些问题，但目前尚不可用。
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.
基于用户域结构的RADIUS请求聚合意味着以相同顶级域结尾的域被路由到相同的服务器，即，路由到公共管理域。国家代码顶级域（CCTLD）映射到国家教育联盟（national eduroam federations），这一点适用于国家代码顶级域（CCTLD），但通用顶级域（GTLD）中的领域则不适用。由于无法应用自动映射“领域结束”->“eduroam federation’s server”，gTLDs中的领域在历史上是不受欢迎的。然而，随着eduroam领域管理员需求的增长，有必要在转发规则中创建异常条目；这些领域需要逐个领域映射到它们的eduroam联盟。例如：“kit.edu”（卡尔斯鲁厄研究所fuer Technologie）需要路由到德国联邦服务器，而“iu.edu”（印第安纳大学）需要路由到美国联邦服务器。
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.
虽然CCTLD总共只占用大约50个路由条目（上限约为200个），但如果需要容纳.edu、.org等中的所有单个条目，路由表的潜在大小实际上是无限的。
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.
除此之外，所有这些路由都需要在三个国际根服务器之间同步，并且更新需要手动应用于RADIUS服务器配置文件。随着条目数量的增加，所需更新的频率使得这种方法变得脆弱且容易出错。
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.
RADIUS基于UDP，当其主要用于简单密码认证协议（PAP）请求时，UDP是一个合理的选择，每个方向只需要一次数据包交换。
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.
当通过RADIUS传输EAP时，EAP会话需要多次往返；根据总有效载荷大小，8-10次往返并不少见。丢失一个UDP数据包将导致用户可见的延迟，并可能导致由于没有应答而将服务器标记为死机。eduroam中的代理路径由多个代理组成，所有这些代理都会引入非常小的丢包概率；也就是说，需要的代理越多，故障率就越高。
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.
对于某些EAP类型，根据其承载的确切有效负载大小，RADIUS服务器和/或请求方可选择将请求方的第2层介质允许的尽可能多的EAP数据放入单个RADIUS数据包中，通常为1500字节。在这种情况下，EAP消息周围的RADIUS封装将向整个RADIUS有效负载大小添加更多字节，最终超过1500字节的限制，导致IP层上UDP数据报出现碎片。虽然在理论上这不是一个问题，但在实践中，有证据表明行为不端的防火墙错误地丢弃了非第一个UDP片段；这最终会导致具有此类EAP类型和特定配置的用户拒绝服务。
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.
一种EAP类型被证明是特别有问题的：EAP-TLS。虽然可以将EAP服务器配置为向请求方发送较小的EAP有效负载块（例如，1200字节，以允许另外300字节的RADIUS开销而无碎片），但发送客户端证书的请求方通常不会向用户公开这样的配置细节。因此，当客户端证书的大小超过1500字节时，EAP消息将始终使用最大可能的第2层块大小，这将在从EAP对等到EAP服务器的路径上引入碎片。
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.
前面提到的两种错误源（数据包丢失和片段丢弃）都会给受影响的用户带来很大的挫折。eduroam的运行经验表明，这种情况很难调试，因为它们需要所有eduroam管理员在身份验证路径上进行协调合作。因此，eduroam社区正在开发监控工具，帮助定位碎片问题。
Note: For more detailed discussion of these issues, please refer to Section 1.1 of [RFC6613].
注：有关这些问题的更详细讨论，请参考[RFC6613]第1.1节。
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).
RADIUS协议的设计仅预见到选择RADIUS属性的加密，最显著的是用户密码。对于符合[RFC4017]要求的EAP方法，用户凭证不使用用户密码属性传输，并且使用比RADIUS用户密码更加密的加密（通常为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.
尽管如此，EAP的使用并没有加密用户会话的所有个人可识别的细节，因为其中一些是在明文RADIUS属性中携带的。具体地，可以通过检查呼叫站ID属性来识别用户的设备；并且用户的位置可以通过观察NAS IP地址、NAS标识符或操作员名称属性得到。由于这些属性未加密，因此即使是IP层第三方也可以获取相应的数据。在最坏的情况下，这允许创建移动性配置文件。通过从RADIUS聚合代理附近的IP跃点利用RADIUS流量，可以使用此连接元数据（如最近在美国国家安全局（NSA）和英国政府通信总部（GCHQ）发现的事件）进行普遍的被动监视。虽然这是可能的，但作者不知道这是否真的做到了。
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.
这些配置文件不一定能够链接到实际用户，因为EAP允许使用匿名外部身份和受保护的凭证交换。然而，实践经验表明，许多用户忽略了以保护隐私的方式配置他们的请求者，或者他们的请求者不支持这样做。特别是，对于EAP-TLS用户，EAP-TLS身份保护的使用通常不实施，也不能使用。在eduroam，使用EAP-TLS的相关个人和IDP正在使用假名客户端证书以提供更好的隐私。
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.
至少对于涉及用户名的EAP类型而言，一种解决方法是创建和部署预配置的请求者配置，在用户设备首次尝试连接之前，在用户设备中进行所有必需的设置；但这在很大程度上取决于请求者的远程配置可能性。
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
另一个威胁涉及EAP服务器身份验证。尽管密码基础TLS隧道是健全的，但在恳求配置中有一个弱点：许多用户不理解或不愿意投入时间来检查服务器证书或安装可信证书颁发机构（CA）。因此，用户可能很容易
tricked into connecting to an unauthorized EAP server, ultimately leading to a leak of their credentials to that unauthorized third party.
被骗连接到未经授权的EAP服务器，最终导致其凭据泄漏给未经授权的第三方。
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.
注意：有许多不同的、供应商专有的方法可以使用必要的EAP参数预先配置设备（例如，Apple，Inc.的“mobileconfig”和Microsoft的“EAPHost”XML模式）。一些制造商甚至完全缺乏分发EAP配置数据的手段。我们认为，定义一种通用的EAP配置元数据格式是有价值的，这种格式可以在制造商之间使用，理想情况下会导致IEEE 802.1X网络最终用户只需要应用此配置文件就可以使用所需的连接属性安全地配置其任何设备。
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.
另一个可能的隐私威胁涉及在回复消息中传输特定于用户的属性。例如，如果RADIUS服务器发回假设的RADIUS供应商特定属性“用户角色=计算机科学学生”（例如，用于消费SP RADIUS服务器并随后分配到“学生”VLAN），则第三方也可以看到此信息，并且可以将其添加到移动配置文件中。
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.
减轻所有信息泄漏到第三方的唯一方法是保护整个RADIUS数据包有效负载，以便IP层第三方无法提取隐私相关信息。但RFC 2865中规定的半径不提供这种可能性。这激发了[RFC6614]；见第4.1节。
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).
随着参与者数量的不断增加（如前一节所述），操作上的困难导致了eduroam架构的大量更改，进而导致了IETF规范（如引言中所述）。
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
尽管使用IEEE 802.1X和EAP的用户认证保持不变（即终端用户无需更改任何配置），但第3节中报告的问题导致
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].
对EAP消息从SP的RADIUS服务器传输到IdP服务器以及从IdP服务器传输到RADIUS服务器的方式进行了重大改革。如[radsec白皮书]所述，这两个根本性的变化是使用TCP而不是UDP，以及依赖TLS而不是RADIUS对等方之间的共享机密。
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:
如第3.4节所述，RADIUS在UDP上的缺陷保证了寻找RFC 2865[RFC2865]的替代品用于EAP的传输。在理解这一需求时，IETF在其初始版本[RFC3588]中已经指定了RADIUS的指定后续协议Diameter。然而，在eduroam（如下所列）的操作限制范围内，找不到任何单一的软件组合（这一点被认为是正确的，超过十年，且一次修订后的Diameter[RFC6733]）。制约因素包括：
o reasonably cheap to deploy on many administrative domains
o 在许多管理域上部署成本合理
o supporting the application of Network Access Server Requirements (NASREQ)
o 支持网络访问服务器要求（NASREQ）的应用
o supporting EAP application
o 支持EAP应用
o supporting Diameter Redirect
o 支撑直径重定向
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 支持验证最流行的EAP类型（EAP隧道传输层安全（EAP-TTLS）、受保护的EAP（PEAP）和EAP-TLS）的身份验证请求
o possibility to retrieve these credentials from popular back-ends such as MySQL or Microsoft's Active Directory.
o 可以从流行的后端（如MySQL或Microsoft的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.
此外，eduroam参与者手中没有支持Diameter的Wi-Fi接入点，也没有任何制造商制定了支持Diameter的路线图（10多年后，这一点仍然被认为是正确的）。这导致了从半径到直径的无损转换以及从半径到直径的无损转换这一开放性问题——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].
在对Diameter实施情况进行了一段时间的监控之后，很明显，需要一个具有更好兼容性的解决方案，并且需要一个来自现有RADIUS层次结构的合理升级路径。eduroam社区积极参与IETF，以规范RADIUS的若干增强功能，以克服第3节中提到的限制。这个过程的结果是[RFC6614]和[DYN-DISC]。
With its use of TCP instead of UDP, and with its full packet encryption, while maintaining full packet format compatibility with RADIUS/UDP, RADIUS/TLS [RFC6614] allows any given RADIUS link in eduroam to be upgraded without the need of a "flag day".
RADIUS/TLS[RFC6614]使用TCP而不是UDP，并使用完整的数据包加密，同时保持与RADIUS/UDP的完整数据包格式兼容性，从而允许在无需“国旗日”的情况下升级eduroam中的任何给定RADIUS链路。
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:
在第一个升级阶段，经典的eduroam层次结构（通过检查领域做出的转发决策）保持不变。这样，RADIUS/TLS仅仅增强了RADIUS数据报的底层传输。但是，这已经提供了一些关键优势：
o explicit peer reachability detection using long-lived TCP sessions
o 使用长寿命TCP会话的显式对等可达性检测
o protection of user credentials and all privacy-relevant RADIUS attributes
o 保护用户凭据和所有与隐私相关的RADIUS属性
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.
静态层次结构的RADIUS/TLS连接可以通过TLS-PSK[RFC4279]操作模式实现（该模式有效地为RADIUS/UDP的“共享机密”提供了1:1的替换），但由于该操作模式尚未得到广泛支持，eduroam中的所有RADIUS/TLS链路都由TLS进行保护，TLS具有一组经认证的CA颁发的X.509证书。
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.
第一个部署阶段尚未解决路由表复杂性问题（见第3.3节）；介绍RADIUS/TLS服务器的动态发现将涵盖这一方面。
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
1. 如何查找给定领域的负责RADIUS服务器的网络地址
2. how to verify that this realm is an authorized eduroam participant
2. 如何验证此域是否为授权的eduroam参与者
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.
通过将特定于eduroam的服务发现信息放入全局DNS树中，可以相对简单地解决问题1。在eduroam中，这是通过使用S-NAPTR规范[RFC3958]中的NAPTR记录和专用NAPTR服务标签（“x-eduroam:radius.tls”）实现的。NAPTR资源记录的使用配置文件是，只允许“S”类型的委托，不允许使用正则表达式。
A subsequent lookup of the resulting SRV records will eventually yield hostnames and IP addresses of the authoritative server(s) of a given realm.
对结果SRV记录的后续查找最终将生成给定领域的权威服务器的主机名和IP地址。
Example (wrapped for readability):
示例（为了可读性而包装）：
> dig -t naptr education.example.
>dig-t naptr education.example。
;; ANSWER SECTION: education.example. 43200 IN NAPTR 100 10 "s" "x-eduroam:radius.tls" "" _radsec._tcp.eduroam.example.
;; 回答部分：教育。例子。NAPTR 100 10“s”x-eduroam:radius.tls“\u radsec.\u tcp.eduroam.example中的43200。
> dig -t srv _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.
;; 回答部分：_radsec._tcp.eduroam.example。SRV 0 0 2083 tld1.eduroam.example中的43200。
> dig -t aaaa tld1.eduroam.example.
>dig-t aaaa tld1.eduroam.example。
;; ANSWER SECTION:
tld1.eduroam.example. 21751 IN AAAA 2001:db8:1::2
;; ANSWER SECTION:
tld1.eduroam.example. 21751 IN AAAA 2001:db8:1::2
Figure 3: SRV Record Lookup
图3:SRV记录查找
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].
根据这种操作模式的操作经验，eduroam正在为通用AAA用例寻求这种方法的标准化。目前的RADEXT工作组文件是[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.
注：值得一提的是，与静态设置相比，向更复杂、更灵活的系统过渡可能会使整个系统更脆弱。
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.
任何组织都可以将“x-eduroam”NAPTR条目放入其域名服务器，假装是相应领域的eduroam身份提供者。由于eduroam是为异构但封闭的用户组提供的服务，因此需要咨询其他信息源，以验证具有已发现服务器的领域实际上是eduroam参与者。
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/
eduroam联盟选择部署一个单独的PKI，只向授权的eduroam身份提供商和eduroam服务提供商颁发证书。因为RADIUS需要证书/
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.
无论如何，重用PKI是一个简单的解决方案。PKI结构允许多个CA作为信任根（由策略管理机构监督），并要求向已验证的eduroam参与者颁发的证书标有相应的“X509v3策略OID”字段；eduroam RADIUS服务器和客户端需要验证传入证书中是否存在这些OID。
The policies and OIDs can be retrieved from the "eduPKI Trust Profile for eduroam Certificates" [eduPKI].
可以从“eduroam证书的eduPKI信任配置文件”[eduPKI]检索策略和OID。
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.
发现模型目前部署在约10个参与eduroam的国家/地区，通过其NAPTR记录可以发现100多个领域。经验表明，该模型的工作和规模与预期相符，唯一的缺点是，国家eduroam管理员不在本地操作PKI的额外负担造成了巨大的管理复杂性。此外，多个CA的存在和证书吊销列表的定期更新使RADIUS服务器的操作更加复杂。
There are two alternatives to this approach to dynamic server discovery that are monitored by the eduroam community:
除此之外，还有两种动态服务器发现方法可供选择，由eduroam社区监控：
1. DNSSEC + DNS-Based Authentication of Named Entities (DANE) TLSA records
1. 基于DNSSEC+DNS的命名实体认证（DANE）TLSA记录
2. ABFAB Trust Router
2. 信任路由器
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.
对于DNSSEC+DANE TLSA，最大的优点是证书数据本身可以存储在DNS中——如果可以找到新的服务器授权检查位置，可能会淘汰PKI基础设施。其最大的缺点是，DANE规范仅包括客户端到服务器证书检查，而RADIUS/TLS还需要服务器到客户端验证。
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.
对于ABFAB信任路由器，最大的优势是它完全可以在没有证书的情况下工作（通过临时协商TLS-PSK密钥）。缺点是，它目前没有正式指定，也不像其他任何解决方案那样被彻底理解。
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.
由于eduroam服务是一个自治网络联盟，因此几乎没有理由将会计信息从服务提供商传输到任何其他（一般）或用户的身份提供商（特别是）。因此，eduroam的会计被视为服务提供商的本地事务。eduroam合规性声明[eduroam compliance]实际上规定不应转发记帐流量[RFC5280]。
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.
eduroam的静态路由基础设施充当过滤系统，阻止来自配置错误的本地RADIUS服务器的记帐流量。代理服务器配置为通过使用记帐响应响应记帐请求来终止记帐请求流量，以防止孤立记帐请求消息的重新传输。通过动态发现，可通过DNS发现的身份提供者需要自己应用这些过滤措施。这增加了身份提供程序RADIUS配置的复杂性。
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.
漫游会产生责任问题，如[RFC4372]（付费用户标识）所示。由于NAS只能看到用户的（可能是匿名的）外部身份，因此无法将使用情况与特定用户（可能使用多个设备）关联起来。支持[RFC4372]的NAS可以请求付费用户标识，如果由认证RADIUS服务器在访问接受消息中提供，则将此值添加到相应的访问请求数据包中。虽然eduroam没有任何计费机制，但仍然需要识别来自一个特定用户的流量。其中一个原因是防止居住在大学校园附近的用户滥用访客访问权。收费用户身份（见第5.3节）为这个问题提供了完美的答案；然而，据我们所知，在撰写本文时，只有一家硬件供应商（Meru Networks）在其接入点上实现RFC 4372。对于所有其他供应商，需要在接入点连接到的RADIUS服务器上请求“收费用户标识”属性。FreeRADIUS在最新发行版中支持此功能，散热器也可以进行改装。
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
10年的eduroam经验没有暴露任何严重事件。这可以作为适当安全设计的证据，并表明用户意识到他们是可识别的行为是一种有效的威慑。当然，这也可能意味着eduroam运营部门缺乏适当的工具或对服务的实际使用和潜在滥用的洞察。在任何情况下，许多
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.
下面是对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.
例如，欧洲eduroam政策服务定义[eduroam服务定义]描述了事件场景和要采取的行动；在本文件中，我们将介绍相关的技术问题。
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.
最初的实施缺乏可靠的工具，SP无法做出自己的决定，IdP也无法引入仅适用于给定SP的有条件规则。eduroam引入对运营商名称和收费用户身份的支持（见第5.3节）使这两种情况成为可能。
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.
发生事故时的第一个行动是阻止用户在服务提供商处访问eduroam。由于漫游用户的真实身份可能隐藏在匿名/伪造的外部身份后面，因此服务提供商只能依赖用户的领域及其MAC地址；如果身份提供商已经发送了一个收费用户身份（详情请参见第5.3节），则该额外信息可用于更可靠地识别用户。
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.
SP端的第一次尝试可能是基于MAC地址或外部标识进行阻塞。此阻塞可以在EAP身份验证发生之前执行——通常在第一个数据报中，作用于RADIUS属性EAP Message/EAP Response/Identity和CALL-Station-ID。该数据报可以被丢弃（请求者通知超时），也可以通过包含EAP故障的RADIUS访问拒绝进行回复。由于恶意用户可以在连接尝试之间更改其MAC地址和外部身份的本地部分，因此第一次尝试不足以锁定已确定的用户。
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.
作为第二项措施，SP可以让EAP身份验证正常进行，并验证来自RADIUS服务器的最终访问接受响应是否包含付费用户标识（CUI）。如果是，则可以将SP RADIUS服务器配置为将此CUI的所有未来访问接受变为访问拒绝/EAP故障。这一措施是有效的：它完全锁定了一个应该被锁定的用户，并且对其他用户没有副作用，即使是来自同一领域的用户。
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.
如果EAP身份验证未显示CUI，则SP无法可靠地确定相关用户。唯一可靠的信息是用户外部身份的领域部分。SP将需要阻止违规用户所属的整个领域。这是有效的，但不是有效的：它锁定了有问题的用户，但对来自同一领域的所有其他访问用户都有DoS副作用。
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.
在没有CUI句柄的情况下，不愿意采取激烈步骤阻止整个领域的SP将被迫联系相关身份提供商，并要求在IdP端阻止用户。这涉及SP和IdP之间的人机交互，不可能实时进行。
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).
IdP有权完全禁用用户帐户，从而阻止该用户访问所有站点中的eduroam。如果由于SP的请求而阻止了用户（如前一节所述），则可能会更细粒度地阻止对特定SP的访问——如果所述SP随其访问请求一起发送Operator Name属性（详见第5.2节）。
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.
如果IdP决定全局阻止用户，这通常是通过将登录尝试视为凭据错误来完成的：整个EAP对话需要执行到显示真实内部身份的点（在此之前，IdP还不知道哪个用户正在尝试进行身份验证）。这通常与凭证交换的时间点一致。除了检查凭证的有效性之外，身份提供者还检查用户的帐户是否（仍然）符合eduroam使用条件，如果不符合条件，将返回访问拒绝/EAP失败。
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.
很可能存在希望用户锁定的SP和用户的IdP之间的意见不同的情况。例如，SP可能会考虑大量的文件共享协议的下载/下载，因为本地策略是不可接受的，并且希望阻止创建过多流量的用户，但是IDP不会对这些行为产生冒犯，并且不会因为这个SP的观点而将用户锁定在EdurRAM的全球范围内。
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.
在缺少操作员名称属性的情况下，无法仅对给定SP而不是整个eduroam应用登录限制；eduroam资格是IdP的一项全有或全无的决定。
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.
如果存在“操作员名称”属性，则仅当验证尝试源自希望进行此类阻止的SP时，IdP才可以使用此信息使验证尝试失败。即使操作员名称属性从第一个RADIUS访问请求数据报开始可用，EAP身份验证仍需要执行，直到知道真正的内部身份，就像上面的全局阻塞情况一样。操作员姓名只是IdP可以用来做出决定的附加信息。
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.
第5.1.1节和第5.1.2节中描述的措施改变了EAP对话。它们要么在对话开始时创建过早拒绝或超时，要么在对话结束时更改身份验证尝试的结果。
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.
在请求方，这些更改与基础设施故障无法区分：过早拒绝或超时可能是由于RADIUS服务器没有响应，而在对话结束时拒绝可能是用户错误（密码错误）或服务器错误（凭据查找失败）。因此，对于请求者来说，很难向用户传达有意义的错误。新指定的EAP类型TEAP，即隧道可扩展认证协议[RFC7170]，具有将细粒度错误原因代码传输给请求方的方法；这有可能改善未来的情况。
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.
EAP协议预见了一种提供这种用户交互通信的机制：EAP状态机包含允许用户可见通信的状态。在最终EAP失败之前，可以注入额外一轮EAP请求/通知和相应的确认。
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.
然而，轶事证据表明，请求者通常根本不实现EAP状态机的这一部分。报告一个请求者支持它，但只将通知的内容记录在日志文件中——这对最终用户毫无帮助。
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
因此，发现账户冻结的原因和范围被视为带外行动。eduroam用户支持流程要求有身份验证问题的用户首先联系他们的身份提供商（通过未指定的方式，例如，他们可以打电话给他们的IdP或通过3G备份链路发送电子邮件）。如果身份提供者阻止了他们的访问，他们会立即通知用户。如果阻塞的原因在SP端，则身份提供程序将通知用户
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.
该帐户处于正常工作状态，用户需要联系SP IT支持部门以获取进一步信息。在这种情况下，SP端IT支持将通知用户阻塞的原因。
The Operator-Name attribute is defined in [RFC5580] as a means of unique identification of the access site.
操作员名称属性在[RFC5580]中定义为访问站点的唯一标识方式。
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.
eduroam的代理基础设施使得家庭站点无法知道用户在哪里漫游。虽然这可能被视为增强用户隐私的一个积极方面，但它也使得用户支持、漫游统计和阻止违规用户访问eduroam变得更加困难。
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.
鼓励参与eduroam的站点使用领域名称空间添加Operator Name属性，即在给定站点的控制下发送领域名称。
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.
在eduroam中引入操作员名称导致了一个操作问题的识别——分配给该属性的标识符126之前已被一些供应商用于其特定目的，并已包含在几个RADIUS服务器发行版的属性字典中。由于此劫持属性的语法已设置为整数，因此这会引入与RFC定义（将其定义为文本）的语法冲突。eduroam中的运行测试表明，使用属性126的整数语法的服务器可能会将值截断为4个八位字节，甚至会丢弃整个RADIUS数据包（因此无法进行身份验证）。eduroam监控和eduroam测试工具试图定位有问题的站点。[RFC6929]第2.8节澄清了这些数据包的处理。
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.
当服务提供商发送其Operator Name值时，它会为主站点设置条件阻止规则，从而剥夺某些用户对所选站点的访问权。与阻止所有eduroam的用户相比，这样的行动引起的关注要少得多。
In eduroam, the Operator Name is also used for the generation of Chargeable User Identity values.
在eduroam中，操作员名称还用于生成收费用户标识值。
The addition of Operator-Name is a straightforward configuration of the RADIUS server and may be easily introduced on a large scale.
添加操作员名称是RADIUS服务器的一种简单配置，可以方便地大规模引入。
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.
RFC 4372[RFC4372]将计费用户标识（CUI）属性定义为对某些EAP方法中使用匿名标识导致的记帐问题的解答。在eduroam，CUI的主要用途是处理事故，但它也可以加强当地的会计核算。
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.
eduroam策略要求为来自不同站点的请求生成的给定用户CUI应不同（以防止共谋攻击）。因此，eduroam策略要求CUI请求附带运算符名称属性，该属性用作CUI生成算法的输入之一。运营商名称要求被视为RFC 4372[RFC4372]第2.1节所述的“业务要求”，因此符合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.
当eduroam开始考虑使用CUI时，没有NAS实施；因此，唯一的解决方案是将所有CUI支持移动到RADIUS服务器。
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.
CUI请求生成只需要向传出访问请求添加NUL CUI属性；然而，崔的真正实力来自会计。在服务器中实施基于CUI的记帐要求NAS直接使用的身份验证和记帐RADIUS服务器实际上相同，或者至少可以访问公共信息源。在处理访问接受时，身份验证RADIUS服务器必须将接收到的CUI值与设备的呼叫站Id一起存储在临时数据库中。收到记帐请求后，服务器需要使用从数据库读取的CUI值更新数据包。
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.
在eduroam中广泛引入CUI支持将大大简化服务提供商的事件处理。引入本地、每用户访问限制将是可能的。访问过的站点还可以通知主站点引入此类限制，指向CUI值，从而使主站点能够识别用户。当用户在其家庭支持部门报告问题时，原因将已经知道。
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.
eduroam体系结构的设计考虑到了用户凭证的保护，从目前的阅读中可以清楚地看到这一点。然而，运营经验揭示了隐私方面的一些更微妙的问题。
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.
如果用户使用匿名外部身份，SP无法通过将外部身份链接到访问其校园的用户来轻松串通。然而，这给滥用或错误配置的补救带来了问题。不可能找到表现出不想要的行为或其系统已被破坏的用户。
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.
因此，在eduroam中引入了收费用户标识，其构造使得只有用户的IdP才能唯一地标识用户。为了防止共谋攻击，每个用户和每个服务提供商的CUI都必须是唯一的。
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.
通过使用EAP，除了用户的IdP之外，任何人都看不到用户凭据。也就是说，如果选择了足够安全的EAP方法并且EAP没有提前终止。
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.
有一个隐私敏感的用户属性必须向第三方公开，这就是用户所属的领域。eduroam中的路由基于用户标识符的领域部分，因此即使隧道EAP方法中的外部标识可以设置为匿名标识符，它也必须包含用户的领域，因此，如果所讨论的领域包含很少的用户，则可能导致识别用户。这被认为是用户隐私和可用性之间的合理权衡。
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.
由于访问请求（可能）通过多个代理RADIUS服务器，用户的家庭IdP通常无法分辨用户漫游的位置。
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.
然而，引入操作员名称和动态查找（即，IdP和SP之间的直接连接）使家庭IdP能够洞察用户的位置。
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.
本节仅讨论与使用eduroam相关的安全注意事项。对于与IEEE 802.1X、RADIUS和EAP相关的一般考虑，读者可参考相应的规范和其他文献。
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).
eduroam中用户凭据的安全性最终取决于EAP会话期间的EAP服务器验证。因此，eduroam策略要求在基础架构中只允许能够进行相互身份验证的EAP类型，并要求IDP发布唯一标识服务器所需的所有信息（即，通常是EAP服务器的CA证书及其公用名或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:
虽然原则上这使得中间人攻击不可能，但实际上仍然存在几种攻击向量。这些缺陷中的大多数是由于EAP申请人的实施缺陷造成的。示例：
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.
一些请求者只允许指定哪个CA颁发EAP服务器证书；其名称未被选中。因此，任何能够从同一CA获得服务器证书的实体都可以创建自己的EAP服务器，并欺骗最终用户将其凭据提交到该伪造服务器。
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.
为了缓解这一问题，eduroam Operations建议使用专用CA，专门向组织的EAP服务器颁发证书。在这种情况下，任何其他实体都不会从CA获得证书，并且这个请求者的缺陷不再构成安全威胁。
7.1.2. Neither Specification of CA nor Server Name Checks during Bootstrap
7.1.2. 引导过程中既不指定CA也不检查服务器名称
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.
一些请求者允许不安全的引导，因为他们允许简单地选择一个网络，即接受通过指纹识别的传入服务器证书。然后将证书另存为受信任证书，以备以后重新连接时使用。如果用户在初始资源调配期间靠近假热点，他们可能会被骗向假服务器提交凭据；此外，未来他们将被打上只信任那个假冒服务器的烙印。
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].
建议eduroam身份提供商向其用户提供完整的文档，以便设置其请求，而无需不安全的引导快捷方式。此外，eduroam Operations还创建了一个工具，可以对许多请求者进行正确、完整和安全的设置：eduroam CAT[eduroam CAT]。
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 CAT之类的自动资源调配工具，否则用户最初安全地配置EAP请求者是很麻烦的。请求者的用户界面通常会邀请用户使用快捷方式（“不要检查服务器证书”），这些快捷方式更容易设置，或者在不易访问的子菜单中隐藏重要的安全设置。此类快捷方式或安全参数遗漏会使用户受到中间人攻击。
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.
建议eduroam IDP教育其用户安全设置的必要步骤。eduroam研发部正在与请求开发人员联系，以改进他们的用户界面。
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.
EAP外部（“匿名”）身份和EAP内部（“真实”）身份之间没有联系。特别是，它们都可以包含领域名称，并且领域不必完全相同。有可能手工制作外部标识为的数据包user@RealmB，以及user@realmA. 使用eduroam请求路由，服务提供商将假定用户来自realmB并将请求发送到那里。realmB上的服务器检查内部用户名，如果未明确禁用隧道请求内容的代理，则可能会决定将隧道EAP负载发送到realmA，由用户进行身份验证。CUI值可能由realmB上的服务器生成，即使该服务器不是其用户。
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 SP会假定麻烦用户来自realmB，并在那里要求阻止该用户。但是，realmB的操作员对用户没有控制权，只有在为EAP隧道数据启用代理请求日志记录的情况下，才能将用户追溯到其真实来源。
eduroam Identity Providers are advised to explicitly disable proxying on the parts of their RADIUS server configuration that process EAP tunnel data.
建议eduroam身份提供商在其RADIUS服务器配置中处理EAP隧道数据的部分显式禁用代理。
Since eduroam's roaming infrastructure is based on IP and RADIUS, it suffers from the usual DoS attack vectors that apply to these protocols.
由于eduroam的漫游基础设施基于IP和RADIUS，因此它受到适用于这些协议的常见DoS攻击向量的影响。
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.
eduroam热点容易受到边缘网络的典型攻击，如恶意路由器广告（RAs）、恶意DHCP服务器等。值得注意的是，eduroam热点比典型的开放式或“捕获式门户”热点更能抵御恶意用户的DHCP池耗尽，因为DHCP地址只有在成功身份验证后才能租用，从而减少了eduroam帐户持有人（而非普通公众）的可能攻击者池。此外，涉及ARP欺骗或ARP洪泛的攻击也会减少到经过身份验证的用户，因为攻击者需要拥有有效的WPA2会话密钥才能在网络上发送流量。
This section does not discuss standard threats to edge networks and IP networks in general. The following sections describe attack vectors specific to eduroam.
本节一般不讨论边缘网络和IP网络的标准威胁。以下各节描述特定于eduroam的攻击向量。
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).
eduroam基础设施比互联网上可访问的典型服务更能抵御分布式DoS攻击，因为只有在物理上接近eduroam热点时才能触发身份验证流量（无论是启用IEEE 802.1X的有线插座还是Wi-Fi接入点）。
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.
但是，当攻击者在附近时，攻击者可以轻松地进行身份验证尝试，从而穿越整个国际eduroam基础设施；攻击者只需从其物理位置以外的另一个世界区域选择一个域，即可触发需要由SP、SP端国家、世界区域、目标世界区域、目标国家、目标IdP服务器处理的访问请求。只要该领域确实存在，就会在该路径上进行整个EAP对话。由于没有实际凭据，请求最终将被拒绝，但它消耗了整个基础设施的处理能力和带宽，可能会影响所有国际身份验证流量。
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.
EAP是一种锁步协议。eduroam热点上的单个攻击者只能执行一个接一个的EAP会话，因此速率受RADIUS链的往返时间限制。
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.
目前，eduroam每天处理数十万次成功的国际漫游验证（顺便说一句，拒绝访问的次数大约是拒绝访问次数的1.5倍）。由于对物理邻近性的要求，以及EAP的锁步特性导致的速率限制，它需要大量攻击者和时间协调攻击来产生显著负载。到目前为止，eduroam运营部门尚未观察到可合理归因于此类攻击的临界负载情况。
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.
动态发现的引入进一步缓解了这个问题，因为身份验证将不会遍历所有基础架构服务器，从而消除了世界区域聚合服务器这一明显的瓶颈。任何攻击都将直接限制在SP和IdP之间。
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.
在eduroam操作中，观察到很大一部分（失败的）eduroam身份验证是由于用户帐户曾经有效，但同时已取消设置（例如，如果学生毕业后离开大学）。配置的eduroam帐户通常保留在用户设备上，当在eduroam热点附近时，用户设备的操作系统将尝试连接到此网络。
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.
随着eduroam的继续运行，具有剩余配置的设备数量不断增加，有效地创建了一个设备池，在任何可能的情况下都会产生不需要的网络流量。
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.
最近，智能手机被编程为使用云存储和在线备份机制，与第三方保存设备的大部分或全部配置细节。更新个人计算机硬件时，用户可以将旧设置恢复到新设备上。据观察，过期的eduroam帐户可以通过这种方式在用户设备上永久存在。如果这一趋势继续下去，可以想象，不断增长的设备池将阻塞eduroam基础设施，导致认证请求注定失败。
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 创建设备配置的区域性，其中配置配置文件包含“ValidUntil”属性，之后需要重新验证或禁用配置。这需要一种用于资源调配的数据格式以及实现支持。
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.
o 对请求方软件的改进，使其在失败的身份验证上保持状态。例如，如果以前已知的工作配置在30个日历日内未能一致地进行身份验证，则应将其视为过时并禁用。
[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>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<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>.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 2865，DOI 10.17487/RFC2865，2000年6月<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>.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，编辑，“可扩展身份验证协议（EAP）”，RFC 3748，DOI 10.17487/RFC3748，2004年6月<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>.
[RFC4279]Eronen，P.，Ed.和H.Tschofenig，Ed.，“用于传输层安全（TLS）的预共享密钥密码套件”，RFC 4279，DOI 10.17487/RFC4279，2005年12月<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>.
[RFC4372]Adrangi，F.，Lior，A.，Korhonen，J.，和J.Loughney，“收费用户身份”，RFC 4372，DOI 10.17487/RFC4372，2006年1月<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>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<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>.
[RFC5580]Tschofenig，H.，Ed.，Adrangi，F.，Jones，M.，Lior，A.，和B.Aboba，“以半径和直径携带定位物体”，RFC 5580，DOI 10.17487/RFC5580，2009年8月<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>.
[RFC5997]DeKok，A.，“远程身份验证拨入用户服务（RADIUS）协议中状态服务器数据包的使用”，RFC 5997，DOI 10.17487/RFC5997，2010年8月<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>.
[RFC6613]DeKok，A.，“TCP上的半径”，RFC 6613，DOI 10.17487/RFC6613，2012年5月<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>.
[RFC6614]Winter，S.，McCauley，M.，Venaas，S.，和K.Wierenga，“RADIUS的传输层安全（TLS）加密”，RFC 6614，DOI 10.17487/RFC66142012年5月<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>.
[RFC6973]Cooper，A.，Tschofenig，H.，Aboba，B.，Peterson，J.，Morris，J.，Hansen，M.，和R.Smith，“互联网协议的隐私考虑”，RFC 6973，DOI 10.17487/RFC6973，2013年7月<http://www.rfc-editor.org/info/rfc6973>.
[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.
[ABFAB-ARCH]Howlett，J.，Hartman，S.，Tschofenig，H.，Lear，E.，和J.Schaad，“Web之外的联邦访问（ABFAB）体系结构的应用程序桥接”，正在进行的工作，草稿-ietf-ABFAB-ARCH-13，2014年7月。
[dead-realm] Tomasek, J., "Dead-realm marking feature for Radiator RADIUS servers", 2006, <http://www.eduroam.cz/dead-realm/docs/dead-realm.html>.
[死域]Tomasek，J.，“散热器RADIUS服务器的死域标记功能”，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.
[DYN-DISC]Winter，S.和M.McCauley，“RADIUS/TLS和RADIUS/DTLS基于NAI的动态对等发现”，正在进行的工作，草稿-ietf-radext-Dynamic-Discovery-15，2015年4月。
[eduPKI] Delivery of Advanced Network Technology to Europe, "eduPKI Trust Profiles", 2012, <https://www.edupki.org/edupki-pma/ edupki-trust-profiles/>.
[eduPKI]向欧洲交付先进网络技术，“eduPKI信任档案”，2012年<https://www.edupki.org/edupki-pma/ edupki信任配置文件/>。
[eduroam-CAT] Delivery of Advanced Network Technology to Europe, "eduroam CAT", 2012, <https://cat.eduroam.org>.
[eduroam CAT]向欧洲交付先进网络技术，“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合规性]跨欧洲研究和教育网络协会，“eduroam合规性声明”，2011年10月<http://www.eduroam.org/downloads/docs/ eduroam_合规性_声明_v1_0.pdf>。
[eduroam-homepage] Trans-European Research and Education Networking Association, "eduroam Homepage", 2007, <http://www.eduroam.org/>.
[eduroam主页]泛欧研究和教育网络协会，“eduroam主页”，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服务定义]GEANT，“eduroam策略服务定义”，版本2.8，2012年7月<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>.
[eduroam start]Wierenga，K.，“主题：NREN间漫游建议”，致mobility@terena.nl邮寄名单，现称为eduroam的初步提案，2002年5月30日<http://www.terena.org/activities/tf-mobility/ 开始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>.
[IEEE.802.1X]IEEE，“局域网和城域网的IEEE标准-基于端口的网络访问控制”，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>.
[NRNROAMING select]泛欧研究和教育网络协会，“NREN漫游的初步选择”，2003年12月<http://www.terena.org/activities/tf-mobility/ 可交付成果/delG/delG final.pdf>。
[radsec-whitepaper] Open System Consultants, "RadSec: a secure, reliable RADIUS Protocol", October 2012, <http://www.open.com.au/radiator/radsec-whitepaper.pdf>.
[radsec白皮书]开放系统顾问，“radsec:安全可靠的RADIUS协议”，2012年10月<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>.
[RFC3588]Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，DOI 10.17487/RFC3588，2003年9月<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>.
[RFC3958]Daigle，L.和A.Newton，“使用SRV RRs和动态委托发现服务（DDDS）的基于域的应用程序服务定位”，RFC 3958，DOI 10.17487/RFC3958，2005年1月<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>.
[RFC4017]Stanley，D.，Walker，J.，和B.Aboba，“无线局域网的可扩展认证协议（EAP）方法要求”，RFC 4017，DOI 10.17487/RFC4017，2005年3月<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>.
[RFC6733]Fajardo，V.，Ed.，Arkko，J.，Loughney，J.，和G.Zorn，Ed.，“直径基准协议”，RFC 6733，DOI 10.17487/RFC6733，2012年10月<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>.
[RFC6929]DeKok，A.和A.Lior，“远程身份验证拨入用户服务（RADIUS）协议扩展”，RFC 6929，DOI 10.17487/RFC6929，2013年4月<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>.
[RFC7170]Zhou，H.，Cam Winget，N.，Salowey，J.，和S.Hanna，“隧道可扩展认证协议（TEAP）版本1”，RFC 7170，DOI 10.17487/RFC7170，2014年5月<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>.
[RFC7542]DeKok，A.，“网络访问标识符”，RFC 7542，DOI 10.17487/RFC7542，2015年5月<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.
作者要感谢Geant协会移动和网络中间件工作组以及Geant项目的参与者的评论和贡献。特别感谢Jim Schaad对第一版做了出色的评审，感谢他和Alan DeKok对第一版做了额外的评审。
The eduroam trademark is registered by TERENA.
eduroam商标由TERENA注册。
Authors' Addresses
作者地址
Klaas Wierenga Cisco Systems Haarlerbergweg 13-17 Amsterdam 1101 CH The Netherlands
克拉斯·维伦加思科系统公司哈勒贝格韦格13-17阿姆斯特丹1101 CH荷兰
Phone: +31 20 357 1752
Email: klaas@cisco.com
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
斯特凡冬季基金会RESTENA Maison du Savoir 2号，卢森堡阿尔泽特河畔大学大道l-4365号
Phone: +352 424409 1 Fax: +352 422473 Email: stefan.winter@restena.lu URI: http://www.restena.lu.
电话：+352 424409 1传真：+352 422473电子邮件：stefan。winter@restena.luURI:http://www.restena.lu.
Tomasz Wolniewicz Nicolaus Copernicus University pl. Rapackiego 1 Torun Poland
托马斯沃尼维茨尼古拉斯哥白尼大学波兰托伦市拉帕基戈1号
Phone: +48-56-611-2750
Fax: +48-56-622-1850
Email: twoln@umk.pl
URI: http://www.home.umk.pl/~twoln/
Phone: +48-56-611-2750
Fax: +48-56-622-1850
Email: twoln@umk.pl
URI: http://www.home.umk.pl/~twoln/