[要約] 要約：RFC 7593は、ネットワークローミングのためのeduroamアーキテクチャについての標準化ドキュメントです。目的は、教育機関や研究機関などのユーザーがセキュアかつ簡単に異なるネットワーク間を移動できるようにすることです。
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サービスのアーキテクチャについて説明します。 IEEE 802.1X、拡張認証プロトコル（EAP）、およびeduroamで使用されるRADIUSの組み合わせにより、ローミングネットワークアクセスに安全でスケーラブルな展開可能なサービスが提供されます。教育部門における過去10年間のeduroamの展開の成功は、他の部門の例として役立つ可能性があるため、このドキュメントを参照してください。特に、最初のアーキテクチャの選択と標準の選択が、運用経験によって促された変更とともに説明されています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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 Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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
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年以上後、このサービスは10,000を超えるサービス拠点に拡大し、南極を除くすべての大陸で数百万のユーザーにサービスを提供しています。
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の設計に関する考慮事項を説明するだけでなく、運用上の経験と、TCP上のRADIUS [RFC6613]やRADIUS with TLS [RFC6614]などのIETF仕様につながり、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-homepage]のオリジナルのアーキテクチャについて説明しています。次に、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]のID管理とプライバシーの用語を使用しています。特に、このドキュメントでは、「アイデンティティプロバイダー」、「サービスプロバイダー」、および「アイデンティティ管理」という用語を使用しています。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 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）は、ユーザーがネットワークリソースの使用を許可されているかどうかを判断できる必要があります。さらに、リソースが乱用された場合、ユーザーを一意に識別できるようにする必要があります（ユーザーのIDプロバイダー（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.
組織とユーザーの両方がローミングインフラストラクチャに簡単に参加できる必要があります。そうでなければ、それは大規模な採用を妨げる可能性があります。特に、クライアントのインストールはなく（または簡単でなければなりません）、構成は1回だけです。
- Secure
- 安全
An important design criterion has been that there needs to be a security association between the end user and their Identity Provider, eliminating the possibility of credential theft. The minimal requirements for security are specified in the eduroam policy and subject to change over time. As an additional protection against user errors and negligence, it should be possible for participating Identity Providers to add their own requirements for the quality of authentication of their own users without the need for the infrastructure as a whole to implement the same requirements.
重要な設計基準は、資格情報の盗難の可能性を排除して、エンドユーザーとそのIDプロバイダーの間にセキュリティアソシエーションが必要であることです。セキュリティの最小要件は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].
3つのアーキテクチャが試されました。1つはVPNテクノロジーの使用に基づいており（安全と見なされますがスケーラブルではありません）、1つはWebキャプティブポータルに基づいており（スケーラブルだが安全ではありません）、IEEE 802.1Xに基づいています。現在はeduroamアーキテクチャです。候補となるアーキテクチャとそれらの相対的なメリットの概要は、[nrenroaming-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のようなフェデレーションは、基本的に2つのタイプの直接信頼関係（および1つは間接的）を実装します。エンドユーザーと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.
これら2つの形式の信頼関係は、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ユーザーにネットワークアクセス（SP）を提供する組織は、承認されたユーザーのみがアクセスできるようにすることができます。ユーザー（またはユーザーのサプリカント）がアクセスリクエストをSPのオーセンティケーター（Wi-Fiアクセスポイントまたはスイッチ）に送信し、オーセンティケーターがアクセスリクエストをSPの認証サーバーに転送します。ユーザーのホーム組織（IdP）の認証サーバーへのRADIUS階層。
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は、別のeduroam SPのSSIDと競合しない限り、Service Set Identifier（SSID） 'eduroam'をブロードキャストする必要があります。 「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を展開する必要があり、さらに、Temporal Key Integrity Protocol（WPA / TKIP）を使用してWi-Fi Protected Accessをサポートする場合があります。レガシーハードウェアのユーザー。
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]の使用には、2つの目的があります。そもそも、適切に選択されたEAP方式により、ユーザーの資格情報を完全に保護し、機密情報を自組織に転送できます。第2に、RADIUSパケット内のEAP方式に関係なく、すべてのRADIUSサーバーがアクセス要求を透過的にプロキシすることにより、EAP方式の選択は、ユーザーの「ホーム」組織とユーザーの間で行われます。つまり、原則として、eduroamポリシーサービス定義[eduroam-service-definition]で規定されている最小要件に準拠している限り、EAP内で使用できるすべての認証フォームをeduroamで使用できます。
+-----+
/ \
/ \
/ \
/ \
,----------\ | | ,---------\
| 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メッセージの外部IDに基づいています。これらの外部IDは、[RFC7542]のように必須のレルムを持つ有効なユーザーIDである必要があります。つまり、something @ realmまたは@realmの形式である必要があります。レルム部分はIdPが所属する機関のドメイン名です。資格情報の保護を維持するために、参加組織は相互認証を提供するEAPメソッドを展開する必要があります。外部IDをサポートするEAP方式では、匿名の外部IDが推奨されます。 eduroamで最も一般的に使用されるのは、ユーザー認証情報が送信されるサーバー認証済みTLS [RFC5246]トンネルを最初に作成する、いわゆるトンネルEAPメソッドです。図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].
注：TLSを使用したRADIUSでの作業の動機となったRADIUSセキュリティに関する説明については、セキュリティに関する考慮事項も参照してください[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トラストファブリックは、大まかにDNS階層に基づいたRADIUSサーバー（組織、国、グローバル）のプロキシ階層で構成されています。つまり、通常、組織の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
Figure 2: eduroam RADIUS Hierarchy
図2：eduroam RADIUS階層
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へのアクセス要求のルーティングは、外部IDの領域部分に基づいて行われます。たとえば（図2のように）、SURFnet（surfnet.nl）のユーザーpaul@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のサプリカントは、外部アクセスIDがanonymous@surfnet.nlであるUTKのアクセスポイント（Authenticator）にEAPアクセス要求を送信します。
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 「.nl」ドメインはルートサーバーに認識されているため、ルートRADIUSサーバーは.nl RADIUSサーバーに要求をプロキシします。
o The .nl RADIUS server proxies the request to the surfnet.nl server, since it knows the SURFnet server.
o .nl RADIUSサーバーは、SURFnetサーバーを認識しているため、要求をsurfnet.nlサーバーにプロキシします。
o The surfnet.nl RADIUS server decapsulates the EAP message and verifies the user credentials, since the user is known to SURFnet.
o ユーザーはSURFnetに認識されているため、surfnet.nl RADIUSサーバーはEAPメッセージのカプセル化を解除し、ユーザーの資格情報を検証します。
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サーバーは、認証要求（Access-AcceptまたはAccess-Reject）の結果を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サーバーの図は簡略化されています。実際には、ルートサーバーは3つの大陸に分散しており、それぞれが特定のルートサーバーが担当する最上位レルムのリストを保持しています。これは、大陸間ローミングの場合、1つのルートサーバーから別のルートサーバーへの追加のプロキシステップがあることも意味します。また、ノードの物理的な分散は、ノードの論理的な分散をミラーリングする必要はありません。これは、安定性とスケーラビリティに役立ちます。
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の運用の10年間の基礎として機能してきましたが、認証の指数関数的な増加により、パフォーマンスと運用のボトルネックが発生することが予想され、実際にはいくつかのケースですでに集約プロキシ。次のセクションでは、いくつかの欠点とその結果生じる救済について説明します。
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. 誤って推定された状態：プロキシチェーンは1ホップよりも長いため、認証パスのさらに先の失敗は、次のホップの失敗と区別がつきません。
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.
2番目のポイントは、最悪のシナリオでシステムの動作状態に大きな影響を与える可能性があります。1つのレルムのホームサーバーが動作不能であると想像してください。そのレルムのユーザーが国際的にローミングを試み、認証を試みます。ホットスポットの場所にある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 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.
適切なネクストホップ状態の導出がない場合、eduroamの参加者によっていくつかの興味深い概念が導入されました。最も注目すべきは、ネクストホップRADIUSピアではなく、レルムごとにアップ/ダウン状態を考慮するフェイルオーバーロジックです（[詳細はデッドレルム]を参照）。最近、RFC 5997 [RFC5997]の実装と慎重なフェイルオーバーパラメータにより、すべてのホップが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の場合、これにより2つの問題が発生します。
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サーバーやMicrosoftのActive Directoryなどの外部データソースに依存している可能性があり、外部データソースは利用できません。 RADIUSインターフェースがまだ機能している場合、そのようなエラー条件のためにサービスできないAccess-Requestに応答する方法には2つのオプションがあります。
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ワーキンググループでは、2つのアプローチのどちらがより適切であるかについて壮大な議論が行われてきましたが、決定的なものではありませんでした。
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 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.
中間プロキシがダウンストリームRADIUSサーバーから応答を受信しない場合も、同様の考慮事項が適用されます。プロキシは、元の要求に応答しないことを選択する可能性があり、再試行とそのアップストリームピアが自身の可用性について誤った結論に至ることになります。または、Access-Rejectで返信して独自の活発さを示すこともできますが、これもエンドユーザーに影響を与えます。
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.
Status-Serverウォッチドッグリクエストを送信する機能は、ダウンストリームサーバーが応答しない場合（または以前に接続されていないため、以前の動作状態が古くなっている場合）にのみ使用できます。 RADIUS / TLSなどのTCP接続のアクティブなリンク状態監視（セクション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要求の集約は、同じトップレベルドメインで終わるレルムが同じサーバー、つまり共通の管理ドメインにルーティングされることを意味します。これは国のeduroamフェデレーションにマップする国コードトップレベルドメイン（ccTLD）には当てはまりますが、一般的なトップレベルドメイン（gTLD）に存在するレルムには当てはまりません。自動マッピング「レルム終了」->「eduroamフェデレーションのサーバー」を適用できなかったため、gTLDのレルムはこれまで推奨されていませんでした。ただし、eduroamレルム管理者からの需要が高まるにつれ、転送ルールに例外エントリを作成する必要が生じました。このようなレルムは、レルムごとにeduroamフェデレーションにマップする必要があります。例： "kit.edu"（Karlsruher Institut fuer Technologie）はドイツのフェデレーションサーバーにルーティングする必要がありますが、 "iu.edu"（インディアナ大学）はUSAフェデレーションサーバーにルーティングする必要があります。
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.
さらに、これらすべてのルートは3つの国際ルートサーバー間で同期する必要があり、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に基づいています。UDPは、主な用途が単純なパスワード認証プロトコル（PAP）要求であり、各方向でパケット交換が1つだけ必要な場合に合理的な選択でした。
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メディアが許可する限り、通常は1500バイトのEAPデータを単一のRADIUSパケットに入れることを選択する場合があります。その場合、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.
1つのEAPタイプであるEAP-TLSが特に問題であることが判明しました。サプリカントにEAPペイロードの小さなチャンクを送信するようにEAPサーバーを構成することは可能ですが（例：1200バイト、フラグメンテーションなしでRADIUSオーバーヘッドをさらに300バイト可能にする）、クライアント証明書を送信するサプリカントは公開しませんユーザーに対するこのような構成の詳細。その結果、クライアント証明書のサイズが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方式では、ユーザーの資格情報はUser-Password属性を使用して送信されず、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属性内に含まれるものもあるからです。特に、ユーザーのデバイスは、Calling-Station-ID属性を調べることで識別できます。また、ユーザーの場所は、NAS-IP-Address、NAS-Identifier、またはOperator-Name属性を監視することから取得できます。これらの属性は暗号化されていないため、サードパーティの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では匿名の外部IDと保護された資格情報の交換を使用できるため、これらのプロファイルは必ずしも実際のユーザーにリンクできるとは限りません。ただし、実際の経験では、多くのユーザーがプライバシーを保護する方法でサプリカントを構成することを怠るか、サプリカントがそれをサポートしていないことが示されています。特に、EAP-TLSユーザーの場合、EAP-TLS ID保護の使用は通常実装されておらず、使用できません。 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タイプの場合の1つの方法は、最初の接続試行の前にユーザーデバイスで必要なすべての設定を行う事前構成済みのサプリカント構成の作成と展開を追求することです。これは、サプリカントのリモート構成の可能性に大きく依存します。
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 tricked into connecting to an unauthorized EAP server, ultimately leading to a leak of their credentials to that unauthorized third party.
さらなる脅威には、EAPサーバーのIDの検証が含まれます。暗号化の基盤であるTLSトンネルは適切ですが、サプリカントの構成に弱点があります。多くのユーザーは、サーバー証明書の検査や信頼できる認証局（CA）のインストールに時間を費やしたり理解したりしていない。その結果、ユーザーは簡単にだまされて無許可の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.
繰り返しになりますが、この特定の脅威を回避する1つの方法は、最初の接続試行の前にユーザーデバイスで必要なすべての設定を行う事前構成済みのサプリカント構成の作成と展開を追求することです。
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ベンダー固有属性「User-Role = Student of Computer Science」を返す場合（たとえば、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で指定されているRADIUSは、この可能性を提供していません。これは動機づけられた[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のRADIUSサーバーにトランスポートされる方法とその逆の方法の大幅な見直し。 [radsec-whitepaper]で概説されているように、2つの基本的な変更は、UDPの代わりにTCPを使用することと、RADIUSピア間で共有シークレットの代わりにTLSに依存することです。
The deficiencies of RADIUS over UDP as described in Section 3.4 warranted a search for a replacement of RFC 2865 [RFC2865] for the transport of EAP. By the time this need was understood, the designated successor protocol to RADIUS, Diameter, was already specified by the IETF in its intial version [RFC3588]. However, within the operational constraints of eduroam (listed below), no single combination of software could be found (and that is believed to still be true, more than ten years and one revision of Diameter [RFC6733] later). The constraints are:
セクション3.4で説明されているように、RADIUS over UDPの欠陥により、EAPのトランスポートのためのRFC 2865 [RFC2865]の代替の検索が必要でした。この必要性が理解されるまでに、RADIUSの後継プロトコルとして指定されているDiameterは、IETFの最初のバージョン[RFC3588]ですでに指定されています。ただし、eduroam（以下に記載）の運用上の制約の範囲内では、ソフトウェアの単一の組み合わせは見つかりませんでした（これは、10年を超え、Diameter [RFC6733]の1つの改訂版でさえ、まだ正しいと考えられています）。制約は次のとおりです。
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 Diameterリダイレクトのサポート
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年以上経っても、まだ正しいと考えられています）。これにより、RADIUSからDiameterへの、およびその逆のロスレス変換という未解決の問題が生じました。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コミュニティは、セクション3で述べた制限を克服するために、RADIUSに対するいくつかの機能拡張の仕様に向けてIETFに積極的に関与しました。このプロセスの結果は[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".
UDPの代わりにTCPを使用し、完全なパケット暗号化を使用しながら、RADIUS / UDPとの完全なパケット形式の互換性を維持しながら、RADIUS / TLS [RFC6614]は、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リンクは、認定されたCAのセットからのX.509証明書を使用してTLSによって保護されています。
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:
ピアディスカバリを導入する場合、2つの個別の問題に対処する必要がありました。
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.
問題1は、eduroam固有のサービス検出情報をグローバルDNSツリーに入れることで、比較的簡単に対処できます。 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.
;;回答セクション：Education.example。 43200 IN NAPTR 100 10 "s" "x-eduroam：radius.tls" "" _radsec._tcp.eduroam.example。
> 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。 43200 IN SRV 0 0 2083 tld1.eduroam.example。
> dig -t aaaa tld1.eduroam.example.
> dig -t aaaa tld1.eduroam.example。
;; ANSWER SECTION:
tld1.eduroam.example. 21751 IN AAAA 2001:db8:1::2
Figure 3: SRV Record Lookup
図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.
どの組織でも、対応するレルムのeduroamアイデンティティプロバイダーのふりをして、「x-eduroam」NAPTRエントリをドメインネームサーバーに配置できます。 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/ 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.
eduroamコンソーシアムは、承認されたeduroam IDプロバイダーとeduroamサービスプロバイダーにのみ証明書を発行する別のPKIを展開することを選択しました。とにかく、RADIUS / TLSには証明書が必要なので、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].
ポリシーとOIDは、「eduroam証明書のeduPKI信頼プロファイル」[eduPKI]から取得できます。
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.
発見モデルは現在、eduroamに参加する約10か国に導入されており、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コミュニティによって監視される動的サーバー検出へのこのアプローチの2つの代替方法があります。
1. DNSSEC + DNS-Based Authentication of Named Entities (DANE) TLSA records
1. DNSSEC +名前付きエンティティのDNSベースの認証（DANE）TLSAレコード
2. ABFAB Trust Router
2. ABFAB信頼ルーター
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 Trust Routerの最大の利点は、証明書がなくても（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サービスは自律ネットワークの連合であるため、サービスプロバイダーから他の（一般に）またはユーザーのIDプロバイダー（特に）にアカウンティング情報を転送する正当性はほとんどありません。したがって、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サーバーからのアカウンティングトラフィックをブロックするフィルタリングシステムとして機能します。プロキシサーバーは、孤立したAccounting-Requestメッセージの再送信を防ぐために、Accounting-ResponseでAccounting-Requestsに応答することにより、Accounting-Requestトラフィックを終了するように構成されています。動的検出では、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]（有料ユーザーID）で識別されるように、ローミングは説明責任の問題を引き起こします。 NASはユーザーの（匿名の可能性が高い）外部IDしか認識できないため、使用を特定のユーザー（複数のデバイスを使用する可能性がある）と関連付けることはできません。 [RFC4372]をサポートするNASはChargeable-User-Identityを要求でき、認証RADIUSサーバーからAccess-Acceptメッセージで提供されている場合は、この値を対応するAccess-Requestパケットに追加します。 eduroamには課金メカニズムはありませんが、1人の特定のユーザーからのトラフィックを識別することが望ましい場合があります。理由の1つは、大学のキャンパスの近くに住んでいるユーザーによるゲストアクセスの悪用を防ぐためです。課金対象ユーザーID（セクション5.3を参照）は、この問題に対する完全な回答を提供します。ただし、執筆時点では、私たちの知る限りでは、1つのハードウェアベンダー（Meru Networks）のみがアクセスポイントにRFC 4372を実装しています。他のすべてのベンダーの場合、Chargeable-User-Identity属性の要求は、アクセスポイントが接続されている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 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.
eduroamでの10年の経験では、重大な事件は発生していません。これは、適切なセキュリティ設計の証拠と見なされるだけでなく、ユーザーが識別可能であるというユーザーの認識が効果的な抑止力として機能することを示唆しています。もちろん、eduroamの運用には適切なツールがなく、サービスの実際の使用や悪用の可能性に対する洞察がないことも意味します。いずれにせよ、アクセス制御が共有シークレットに基づいているオープンネットワークまたはネットワークに存在する攻撃ベクトルの多くは存在せず、おそらくはるかに安全なシステムにつながります。
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-service-definition]は、例として、発生するインシデントのシナリオとアクションについて説明しています。このドキュメントでは、関連する技術的な問題について説明します。
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にOperator-NameおよびChargeable-User-Identity（セクション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へのユーザーのアクセスをブロックすることです。ローミングユーザーの真のIDは匿名/偽の外部IDの背後に隠されている可能性が高いため、サービスプロバイダーはユーザーのレルムとそのMACアドレスにのみ依存できます。 IDプロバイダーがすでに課金可能なユーザーIDを送信している場合（詳細については、セクション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アドレスまたは外部IDに基づいてブロックすることです。このブロッキングは、EAP認証が発生する前に実行できます。通常、最初のデータグラムで、RADIUS属性EAP-Message / EAP-Response / IdentityおよびCalling-Station-IDに基づいて機能します。データグラムはドロップするか（サプリカントがタイムアウトを通知）、またはEAP-Failureを含むRADIUS Access-Rejectで応答できます。悪意のあるユーザーは、接続試行の間にMACアドレスと外部IDのローカル部分の両方を変更できるため、この最初の試行では、特定のユーザーをロックアウトするには不十分です。
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.
2番目の手段として、SPはEAP認証を通常どおりに進行させ、RADIUSサーバーからの最終的なAccess-Accept応答にChargeable-User-Identity（CUI）が含まれているかどうかを確認できます。その場合、SP RADIUSサーバーは、このCUIの今後のすべてのAccess-AcceptをAccess-Reject / EAP-Failureに変換するように構成できます。この方法は効果的かつ効率的です。ロックアウトされるはずの1人のユーザーを正確にロックアウトし、同じレルムからであっても、他のユーザーへの副作用はありません。
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は問題のユーザーを確実に特定できません。影響を受ける唯一の信頼できる情報は、ユーザーの外部IDの領域部分です。 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は、問題のIDプロバイダーに連絡し、ユーザーを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属性を一緒に送信する場合彼のAccess-Requests（詳細はセクション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がユーザーをグローバルにブロックすることを決定した場合、これは通常、資格情報が間違っているかのようにログイン試行を処理することによって行われます。真の内部IDが明らかになるまでEAP会話全体を実行する必要があります（その前に、IdPどのユーザーが認証しようとしているのかまだわかりません）。これは通常、資格情報が交換される時点と一致します。資格情報の有効性をチェックする代わりに、またはそれに加えて、アイデンティティプロバイダーは、ユーザーのアカウントが（まだ）eduroamの使用資格があるかどうかもチェックし、資格がない場合はAccess-Reject / EAP-Failureを返します。
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はそのようなアクションに不快感を与えないため、この1つのSPの意見により、彼のユーザーをグローバルにeduroamからロックアウトします。
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.
Operator-Name属性がない場合、特定の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.
Operator-Name属性が存在する場合、IdPはこの情報を使用して、認証の試行がそのようなブロックを希望するSPから発生した場合にのみ失敗する可能性があります。 Operator-Name属性は最初のRADIUS Access-Requestデータグラム以降で使用できますが、上記のグローバルブロッキングの場合と同様に、真の内部IDがわかるまでEAP認証を実行する必要があります。 Operator-Nameは、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、Tunnel Extensible Authentication Protocol [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プロトコルは、このようなユーザー対話型通信を提供する1つのメカニズムを予測しています。EAPステートマシンには、ユーザーが認識できる通信を可能にする状態が含まれています。 EAP-Request / Notificationの追加ラウンドと対応する確認応答は、最後のEAP-Failureの前に挿入できます。
However, anecdotal evidence suggests that supplicants typically do not implement this part of the EAP state machine at all. One supplicant is reported to support it, but only logs the contents of the notification in a log file -- which is not at all helpful for the end user.
ただし、事例証拠により、サプリカントは通常、EAPステートマシンのこの部分をまったく実装しないことが示唆されています。 1つのサプリカントがそれをサポートすると報告されていますが、通知の内容をログファイルに記録するだけです。これは、エンドユーザーにはまったく役立ちません。
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 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.
したがって、理由の発見とアカウントのブロックの範囲は、帯域外のアクションとして残されます。 eduroamのユーザーサポートプロセスでは、認証に問題のあるユーザーが最初の手段としてアイデンティティプロバイダーに連絡する必要があります（たとえば、不特定の手段により、IdPに電話したり、3Gバックアップリンク経由でメールを送信したりできます）。 IDプロバイダーがアクセスをブロックしたものである場合、ユーザーはすぐに通知を受けます。ブロックの理由がSP側にある場合、IDプロバイダーは代わりにユーザーにアカウントが正常に機能していること、さらに詳しい情報を得るためにSPのITサポートに連絡する必要があることをユーザーに通知します。その場合、そのSP側のITサポートは、ブロックの理由についてユーザーに通知します。
The Operator-Name attribute is defined in [RFC5580] as a means of unique identification of the access site.
Operator-Name属性は、アクセスサイトを一意に識別する手段として[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に参加しているサイトでは、REALM名前空間を使用して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にOperator-Nameが導入されたことで、1つの運用上の問題が特定されました。この属性に割り当てられた識別子126は、特定の目的のために一部のベンダーによって以前に使用されており、いくつかのRADIUSサーバー配布の属性辞書に含まれています。このハイジャックされた属性の構文はIntegerに設定されていたため、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では、オペレーター名は課金対象ユーザーID値の生成にも使用されます。
The addition of Operator-Name is a straightforward configuration of the RADIUS server and may be easily introduced on a large scale.
Operator-Nameの追加は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.
Chargeable-User-Identity（CUI）属性は、RFC 4372 [RFC4372]で、一部のEAPメソッドでの匿名IDの使用によって引き起こされるアカウンティングの問題に対する回答として定義されています。 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生成アルゴリズムの入力の1つとして使用されるOperator-Name属性を伴うことが義務付けられています。 Operator-Name要件は、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要求の生成では、発信Access-RequestにNUL CUI属性を追加するだけで済みます。ただし、CUIの本当の強みは会計処理にあります。サーバーにCUIベースのアカウンティングを実装するには、NASが直接使用する認証およびアカウンティングRADIUSサーバーが実際に同じであるか、少なくとも共通の情報ソースにアクセスできる必要があります。 Access-Acceptの処理時に、認証を行うRADIUSサーバーは、受信したCUI値をデバイスのCalling-Station-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.
ユーザーが匿名の外部IDを使用している場合、SPは、キャンパスにアクセスしているユーザーに外部IDをリンクすることで簡単に共謀することはできません。ただし、これにより、乱用または設定ミスの修正に問題が生じます。望ましくない動作を示したり、システムが危険にさらされているユーザーを見つけることは不可能です。
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.
そのため、有料ユーザーIDが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.
プライバシーに敏感なユーザー属性が1つあり、これは必ず第三者に公開され、ユーザーが属するレルムです。 eduroamでのルーティングは、ユーザー識別子の領域部分に基づいているため、トンネルEAPメソッドの外部IDが匿名識別子に設定されている場合でも、ユーザーの領域が含まれている必要があるため、ユーザーの識別につながる可能性があります。問題のレルムに含まれるユーザーが少ない場合。これは、ユーザーのプライバシーと使いやすさの間の妥当なトレードオフと見なされます。
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.
ただし、Operator-Nameと動的ルックアップ（つまり、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は、組織のEAPサーバーにのみ証明書を発行するプライベートCAの使用を提案しています。その場合、他のエンティティは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 IDプロバイダーは、安全でないブートストラップのショートカットなしで、サプリカントのセットアップに関する完全なドキュメントをユーザーに提供することをお勧めします。さらに、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 Research and Developmentは、サプリカントの開発者と連絡を取り、ユーザーインターフェイスを改善しています。
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外部（「匿名」）IDとEAP内部（「実際の」）IDの間にリンクはありません。特に、両方にレルム名を含めることができ、レルムは同一である必要はありません。外部IDがuser @ RealmB、内部IDが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 IDプロバイダーは、EAPトンネルデータを処理するRADIUSサーバー構成の部分でプロキシを明示的に無効にすることをお勧めします。
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ホットスポットは、不正なルーターアドバタイズ（RA）、不正な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）に近接している場合にのみ実行できるためです。 -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ホットスポットにいる1人の攻撃者は、EAP会話を1つずつしか実行できないため、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日あたり数十万件の成功した国際ローミング認証を処理します（偶然にも、約1.5倍のアクセス拒否）。物理的な近接性の要件、およびEAPのロックステップの性質によって引き起こされるレート制限により、かなりの負荷を生成するために、かなりの量の攻撃者と時間調整された攻撃が必要になります。これまでのところ、eduroam Operationsは、そのような攻撃に起因する合理的な原因となる可能性がある重大な負荷状態をまだ観察していません。
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 Operationsでは、（失敗した）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、「Remote Authentication Dial In User Service（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、編、「Extensible Authentication Protocol（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、編、「トランスポート層セキュリティ（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、「Chargeable User Identity」、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、「The Transport Layer Security（TLS）Protocol Version 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 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、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、「RADIUSおよびDiameterでのロケーションオブジェクトのキャリング」、RFC 5580、DOI 10.17487 / RFC5580、8月2009、<http://www.rfc-editor.org/info/rfc5580>。
[RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol", RFC 5997, DOI 10.17487/RFC5997, August 2010, <http://www.rfc-editor.org/info/rfc5997>.
[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。、「RADIUS over 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.、and K. Wierenga、 "Transport Layer Security（TLS）Encryption for RADIUS"、RFC 6614、DOI 10.17487 / RFC6614、May 2012、<http：/ /www.rfc-editor.org/info/rfc6614>。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <http://www.rfc-editor.org/info/rfc6973>.
[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>.
[dead-realm] Tomasek、J。、「Radiator 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]冬、S。およびM.マッコーリー、「RADIUS / TLSおよびRADIUS / DTLSのためのNAIベースの動的ピア検出」、作業中、draft-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 Trust Profiles」、2012、<https://www.edupki.org/edupki-pma/ edupki-trust-profiles />。
[eduroam-CAT] Delivery of Advanced Network Technology to Europe, "eduroam CAT", 2012, <https://cat.eduroam.org>.
[eduroam-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-compliance] Trans-European Research and Education Networking Association、「eduroam Compliance Statement」、2011年10月、<http://www.eduroam.org/downloads/docs/ eduroam_Compliance_Statement_v1_0.pdf>。
[eduroam-homepage] Trans-European Research and Education Networking Association, "eduroam Homepage", 2007, <http://www.eduroam.org/>.
[eduroam-homepage] Trans-European Research and Education Networking Association、「eduroam Homepage」、2007年、<http://www.eduroam.org/>。
[eduroam-service-definition] GEANT, "eduroam Policy Service Definition", Version 2.8, July 2012, <https://www.eduroam.org/downloads/docs/GN3-12- 192_eduroam-policy-service-definition_ver28_26072012.pdf>.
[eduroam-service-definition] GEANT、「eduroam Policy Service Definition」、バージョン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 / start-of-eduroam.pdf>。
[IEEE.802.1X] IEEE, "IEEE Standard for Local and metropolitan area networks - Port-Based Network Access Control", IEEE 802.1X-2010, DOI 10.1109/ieeestd.2010.5409813, <http://ieeexplore.ieee.org/servlet/ opac?punumber=5409757>.
[IEEE.802.1X] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Port-Based Network Access Control」、IEEE 802.1X-2010、DOI 10.1109 / ieeestd.2010.5409813、<http://ieeexplore.ieee.org/ servlet / opac？punumber = 5409757>。
[nrenroaming-select] Trans-European Research and Education Networking Association, "Preliminary selection for inter-NREN roaming", December 2003, <http://www.terena.org/activities/tf-mobility/ deliverables/delG/DelG-final.pdf>.
[nrenroaming-select] Trans-European Research and Education Networking Association、「Inter-NREN roamingの予備的な選択」、2003年12月、<http://www.terena.org/activities/tf-mobility/deliveryables/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-whitepaper]オープンシステムコンサルタント、「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、「Diameter Base Protocol」、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 RRおよび動的委任検出サービス（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]スタンリー、D。、ウォーカー、J。、およびB.アボバ、「ワイヤレスLANの拡張認証プロトコル（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.、and G. Zorn、Ed。、 "Diameter Base Protocol"、RFC 6733、DOI 10.17487 / RFC6733、October 2012、<http：/ /www.rfc-editor.org/info/rfc6733>。
[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", RFC 6929, DOI 10.17487/RFC6929, April 2013, <http://www.rfc-editor.org/info/rfc6929>.
[RFC6929] DeKok、A。およびA. Lior、「Remote Authentication Dial In User Service（RADIUS）Protocol Extensions」、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、「Tunnel Extensible Authentication Protocol（TEAP）Version 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。、「The Network Access Identifier」、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 Association Task Forceの参加者と、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
Klaas Wierenga Cisco Systems Haarlerbergweg 13-17アムステルダム1101 CHオランダ
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.lu URI：http://www.restena.lu。
Tomasz Wolniewicz Nicolaus Copernicus University pl. Rapackiego 1 Torun Poland
トマシュウォルニェイチニコラウスコペルニクス大学pl。 Rapackiego 1トルンポーランド
Phone: +48-56-611-2750
Fax: +48-56-622-1850
Email: twoln@umk.pl
URI: http://www.home.umk.pl/~twoln/