[要約] RFC 7585は、RADIUS/TLSおよびRADIUS/DTLSに基づく動的なピアの発見をNAIに基づいて行うための仕様です。このRFCの目的は、セキュアなネットワークアクセスのためにピアの自動検出を可能にすることです。
Internet Engineering Task Force (IETF) S. Winter
Request for Comments: 7585 RESTENA
Category: Experimental M. McCauley
ISSN: 2070-1721 AirSpayce
October 2015
Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI)
ネットワークアクセス識別子（NAI）に基づくRADIUS / TLSおよびRADIUS / DTLSの動的ピア検出
Abstract
概要
This document specifies a means to find authoritative RADIUS servers for a given realm. It is used in conjunction with either RADIUS over Transport Layer Security (RADIUS/TLS) or RADIUS over Datagram Transport Layer Security (RADIUS/DTLS).
このドキュメントでは、特定のレルムに対して信頼できるRADIUSサーバーを見つける方法を指定します。 RADIUS over Transport Layer Security（RADIUS / TLS）またはRADIUS over Datagram Transport Layer Security（RADIUS / DTLS）と組み合わせて使用されます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 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/rfc7585.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7585で入手できます。
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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Document Status . . . . . . . . . . . . . . . . . . . . . 6
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. DNS Resource Record (RR) Definition . . . . . . . . . . . 7
2.1.1. S-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2. SRV . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.3. Optional Name Mangling . . . . . . . . . . . . . . . 12
2.2. Definition of the X.509 Certificate Property
SubjectAltName:otherName:NAIRealm . . . . . . . . . . . . 14
3. DNS-Based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . 16
3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Configuration Variables . . . . . . . . . . . . . . . . . 16
3.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4. Realm to RADIUS Server Resolution Algorithm . . . . . . . 17
3.4.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.2. Output . . . . . . . . . . . . . . . . . . . . . . . 18
3.4.3. Algorithm . . . . . . . . . . . . . . . . . . . . . . 18
3.4.4. Validity of Results . . . . . . . . . . . . . . . . . 20
3.4.5. Delay Considerations . . . . . . . . . . . . . . . . 21
3.4.6. Example . . . . . . . . . . . . . . . . . . . . . . . 21
4. Operations and Manageability Considerations . . . . . . . . . 24
5. Security Considerations . . . . . . . . . . . . . . . . . . . 25
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. ASN.1 Syntax of NAIRealm . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
RADIUS in all its current transport variants (RADIUS/UDP, RADIUS/TCP, RADIUS/TLS, and RADIUS/DTLS) requires manual configuration of all peers (clients and servers).
現在のすべてのトランスポートバリアント（RADIUS / UDP、RADIUS / TCP、RADIUS / TLS、RADIUS / DTLS）のRADIUSでは、すべてのピア（クライアントとサーバー）を手動で構成する必要があります。
Where more than one administrative entity collaborates for RADIUS authentication of their respective customers (a "roaming consortium"), the Network Access Identifier (NAI) [RFC7542] is the suggested way of differentiating users between those entities; the part of a username to the right of the "@" delimiter in an NAI is called the user's "realm". Where many realms and RADIUS forwarding servers are in use, the number of realms to be forwarded and the corresponding number of servers to configure may be significant. Where new realms with new servers are added or details of existing servers change on a regular basis, maintaining a single monolithic configuration file for all these details may prove too cumbersome to be useful.
複数の管理エンティティがそれぞれの顧客（「ローミングコンソーシアム」）のRADIUS認証のために協力している場合、ネットワークアクセス識別子（NAI）[RFC7542]は、これらのエンティティ間でユーザーを区別するための推奨される方法です。ユーザー名のうち、NAIの「@」区切り文字の右側にある部分は、ユーザーの「レルム」と呼ばれます。多くのレルムとRADIUS転送サーバーが使用されている場合、転送されるレルムの数と、対応する構成するサーバーの数が重要になることがあります。新しいサーバーを備えた新しいレルムが追加されたり、既存のサーバーの詳細が定期的に変更されたりする場合、これらすべての詳細に対して単一のモノリシック構成ファイルを維持するのは面倒すぎて役に立たないことがあります。
Furthermore, in cases where a roaming consortium consists of independently working branches (e.g., departments and national subsidiaries), each with their own forwarding servers, and who add or change their realm lists at their own discretion, there is additional complexity in synchronizing the changed data across all branches.
さらに、ローミングコンソーシアムが、それぞれ独自の転送サーバーを持ち、独自の裁量でレルムリストを追加または変更する、独立して機能するブランチ（部門や国の子会社など）で構成される場合、変更された同期にさらに複雑さが伴います。すべてのブランチにわたるデータ。
Where realms can be partitioned (e.g., according to their top-level domain (TLD) ending), forwarding of requests can be realized with a hierarchy of RADIUS servers, all serving their partition of the realm space. Figure 1 shows an example of this hierarchical routing.
レルムを分割できる場合（たとえば、トップレベルドメイン（TLD）の末尾に従って）、リクエストの転送はRADIUSサーバーの階層で実現でき、すべてレルムスペースのパーティションにサービスを提供します。図1は、この階層型ルーティングの例を示しています。
+-------+
| |
| . |
| |
+---+---+
/ | \
+----------------/ | \---------------------+
| | |
| | |
| | |
+--+---+ +--+--+ +----+---+
| | | | | |
| .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 1: RADIUS Hierarchy Based on Top-Level Domain Partitioning
図1：トップレベルドメインパーティショニングに基づくRADIUS階層
However, such partitioning is not always possible. As an example, in one real-life deployment, the administrative boundaries and RADIUS forwarding servers are organized along country borders, but generic top-level domains such as .edu do not map to this choice of boundaries (see [RFC7593] for details). These situations can benefit significantly from a distributed mechanism for storing realm and server reachability information. This document describes one such mechanism: storage of realm-to-server mappings in DNS; realm-based request forwarding can then be realized without a static hierarchy such as in the following figure:
ただし、このような分割は常に可能とは限りません。例として、実際の1つの展開では、管理境界とRADIUS転送サーバーは国境に沿って編成されていますが、.eduなどの一般的なトップレベルドメインは、この境界の選択にマップされません（詳細は[RFC7593]を参照） 。これらの状況は、レルムとサーバーの到達可能性情報を格納するための分散メカニズムから大きなメリットを得られます。このドキュメントでは、そのようなメカニズムの1つについて説明します。DNSでのレルムからサーバーへのマッピングの保存。レルムベースのリクエスト転送は、次の図のような静的階層なしで実現できます。
---------
/ \
--------- ------------
/ \
| DNS -
----------| \
/ \ surfnet.nl NAPTR? |
(1) / ---- -> radius.surfnet.nl /
/ \ /
/ -------- ---------
/ \---------/
|
| ---------------------------------------
| / (2) RADIUS \
| | |
+---+---+ +----+---+ +----+---+ +--+---+ +-----+----+ +-----+-----+
| | | | | | | | | | | |
|utk.edu| |utah.edu| |case.edu| |hva.nl| |surfnet.nl| |soton.ac.uk|
| | | | | | | | | | | |
+----+--+ +--------+ +--------+ +------+ +----+-----+ +-----------+
| |
| |
+--+--+ +--+--+
| | | |
+-+-----+-+ | |
| | +-----+
+---------+
user: paul@surfnet.nl surfnet.nl Authentication server
Figure 2: RADIUS Hierarchy Based on Top-Level Domain Partitioning
図2：トップレベルドメインパーティショニングに基づくRADIUS階層
This document also specifies various approaches for verifying that server information that was retrieved from DNS was from an authorized party; for example, an organization that is not at all part of a given roaming consortium may alter its own DNS records to yield a result for its own realm.
このドキュメントでは、DNSから取得されたサーバー情報が承認された当事者からのものであることを確認するためのさまざまなアプローチについても説明しています。たとえば、特定のローミングコンソーシアムの一部ではない組織は、独自のDNSレコードを変更して、独自のレルムの結果を生成する場合があります。
In this document, several words are used to signify the requirements of the specification. 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]で説明されているように解釈されます。
RADIUS/TLS Client: a RADIUS/TLS [RFC6614] instance that initiates a new connection.
RADIUS / TLSクライアント：新しい接続を開始するRADIUS / TLS [RFC6614]インスタンス。
RADIUS/TLS Server: a RADIUS/TLS [RFC6614] instance that listens on a RADIUS/TLS port and accepts new connections.
RADIUS / TLSサーバー：RADIUS / TLSポートで待機し、新しい接続を受け入れるRADIUS / TLS [RFC6614]インスタンス。
RADIUS/TLS Node: a RADIUS/TLS client or server.
RADIUS / TLSノード：RADIUS / TLSクライアントまたはサーバー。
[RFC7542] defines the terms NAI, realm, and consortium.
[RFC7542]は、NAI、レルム、コンソーシアムという用語を定義しています。
This document is an Experimental RFC.
このドキュメントは試験的なRFCです。
The communities expected to use this document are roaming consortia whose authentication services are based on the RADIUS protocol.
このドキュメントを使用する予定のコミュニティは、認証サービスがRADIUSプロトコルに基づいているローミングコンソーシアムです。
The duration of the experiment is undetermined; as soon as enough experience is collected on the choice points mentioned below, it is expected to be obsoleted by a Standards Track version of the protocol, which trims down the choice points.
実験の期間は未定です。下記の選択ポイントで十分な経験が収集されるとすぐに、選択ポイントを削減するプロトコルの標準トラックバージョンによって廃止されることが予想されます。
If that removal of choice points obsoletes tags or service names as defined in this document and allocated by IANA, these items will be returned to IANA as per the provisions in [RFC6335].
この選択ポイントの削除により、このドキュメントで定義され、IANAによって割り当てられたタグまたはサービス名が廃止された場合、これらのアイテムは[RFC6335]の規定に従ってIANAに返されます。
The document provides a discovery mechanism for RADIUS, which is very similar to the approach that is taken with the Diameter protocol [RFC6733]. As such, the basic approach (using Naming Authority Pointer (NAPTR) records in DNS domains that match NAI realms) is not of a very experimental nature.
このドキュメントでは、Diameterプロトコル[RFC6733]で採用されているアプローチと非常によく似た、RADIUSの検出メカニズムを提供しています。そのため、（NAIレルムに一致するDNSドメインでネーミングオーソリティポインタ（NAPTR）レコードを使用する）基本的なアプローチは、あまり実験的な性質のものではありません。
However, the document offers a few choice points and extensions that go beyond the provisions for Diameter. The list of major additions/ deviations is
ただし、このドキュメントには、Diameterの規定を超えるいくつかの選択ポイントと拡張機能が記載されています。主要な追加/逸脱のリストは
o provisions for determining the authority of a server to act for users of a realm (declared out of scope for Diameter)
o レルムのユーザーに代わって動作するサーバーの権限を決定するための規定（Diameterの範囲外として宣言）
o much more in-depth guidance on DNS regarding timeouts, failure conditions, and alteration of Time-To-Live (TTL) information than the Diameter counterpart
o タイムアウト、障害状態、および存続時間（TTL）情報の変更に関するDNSに関する詳細なガイダンスは、Diameterの対応するガイダンスよりもはるかに詳細です。
o a partially correct routing error detection during DNS lookups
o DNSルックアップ中の部分的に正しいルーティングエラーの検出
DNS definitions of RADIUS/TLS servers can be either S-NAPTR records (see [RFC3958]) or SRV records. When both are defined, the resolution algorithm prefers S-NAPTR results (see Section 3.4 below).
RADIUS / TLSサーバーのDNS定義は、S-NAPTRレコード（[RFC3958]を参照）またはSRVレコードのいずれかです。両方が定義されている場合、解決アルゴリズムはS-NAPTR結果を優先します（以下のセクション3.4を参照）。
This specification defines three S-NAPTR service tags:
この仕様では、3つのS-NAPTRサービスタグを定義しています。
+-----------------+-----------------------------------------+
| Service Tag | Use |
+-----------------+-----------------------------------------+
| aaa+auth | RADIUS Authentication, i.e., traffic as |
| | defined in [RFC2865] |
| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
| aaa+acct | RADIUS Accounting, i.e., traffic as |
| | defined in [RFC2866] |
| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
| aaa+dynauth | RADIUS Dynamic Authorization, i.e., |
| | traffic as defined in [RFC5176] |
+-----------------+-----------------------------------------+
Figure 3: List of Service Tags
図3：サービスタグのリスト
This specification defines two S-NAPTR protocol tags:
この仕様では、2つのS-NAPTRプロトコルタグを定義しています。
+-----------------+-----------------------------------------+
| Protocol Tag | Use |
+-----------------+-----------------------------------------+
| radius.tls.tcp | RADIUS transported over TLS as defined |
| | in [RFC6614] |
| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
| radius.dtls.udp | RADIUS transported over DTLS as defined |
| | in [RFC7360] |
+-----------------+-----------------------------------------+
Figure 4: List of Protocol Tags
図4：プロトコルタグのリスト
Note well:
よく注意してください：
The S-NAPTR service and protocols are unrelated to the IANA "Service Name and Transport Protocol Port Number Registry".
S-NAPTRサービスとプロトコルは、IANAの「サービス名とトランスポートプロトコルのポート番号レジストリ」とは関係ありません。
The delimiter "." in the protocol tags is only a separator for human reading convenience -- not for structure or namespacing; it MUST NOT be parsed in any way by the querying application or resolver.
区切り文字「。」プロトコルタグでは、人間が読みやすくするための区切り文字にすぎません。構造や名前空間ではありません。クエリを実行するアプリケーションまたはリゾルバーによって決して解析されてはなりません。
The use of the separator "." is common also in other protocols' protocol tags. This is coincidence and does not imply a shared semantics with such protocols.
セパレータ「。」の使用。他のプロトコルのプロトコルタグでも一般的です。これは偶然の一致であり、そのようなプロトコルで共有されるセマンティクスを意味するものではありません。
RADIUS is a time-critical protocol; RADIUS clients that do not receive an answer after a configurable, but short, amount of time will consider the request failed. Due to this, there is little leeway for extensive retries.
RADIUSはタイムクリティカルなプロトコルです。構成可能であるが短時間で応答を受信しないRADIUSクライアントは、要求が失敗したと見なします。このため、大規模な再試行の余地はほとんどありません。
As a general rule, only error conditions that generate an immediate response from the other end are eligible for a retry of a discovered target. Any error condition involving timeouts, or the absence of a reply for more than one second during the connection setup phase, is to be considered a failure; the next target in the set of discovered NAPTR targets is to be tried.
原則として、検出されたターゲットの再試行は、相手側からの即時応答を生成するエラー条件のみが対象です。タイムアウトを含むエラー状態、または接続セットアップフェーズ中に1秒以上応答がない場合は、失敗と見なされます。発見されたNAPTRターゲットのセットの次のターゲットが試行されます。
Note that [RFC3958] already defines that a failure to identify the server as being authoritative for the realm is always considered a failure; so even if a discovered target returns a wrong credential instantly, it is not eligible for retry.
[RFC3958]はすでに、レルムに対して権限があるとサーバーを識別できない場合は常に失敗と見なされることを定義しています。したがって、検出されたターゲットがすぐに間違った資格情報を返した場合でも、再試行の対象にはなりません。
Furthermore, the contacted RADIUS/TLS server verifies during connection setup whether or not it finds the connecting RADIUS/TLS client authorized. If the connecting RADIUS/TLS client is not found acceptable, the server will close the TLS connection immediately with an appropriate alert. Such TLS handshake failures are permanently fatal and not eligible for retry, unless the connecting client has more X.509 certificates to try; in this case, a retry with the remainder of its set of certificates SHOULD be attempted. Not trying all available client certificates potentially creates a DoS for the end user whose authentication attempt triggered the discovery; one of the neglected certificates might have led to a successful RADIUS connection and subsequent end-user authentication.
さらに、接続されたRADIUS / TLSサーバーは、接続のセットアップ中に、接続しているRADIUS / TLSクライアントが承認されているかどうかを確認します。接続しているRADIUS / TLSクライアントが受け入れ可能でない場合、サーバーは適切なアラートを使用してTLS接続をすぐに閉じます。このようなTLSハンドシェイクの失敗は永久に致命的であり、再試行の対象にはなりません。ただし、接続しているクライアントが試すX.509証明書がない場合。この場合、証明書の残りのセットを使用して再試行する必要があります。使用可能なすべてのクライアント証明書を試行するわけではないため、認証試行が検出をトリガーしたエンドユーザーのDoSを作成する可能性があります。無視された証明書の1つがRADIUS接続とそれに続くエンドユーザー認証に成功した可能性があります。
If the TLS session setup to a discovered target does not succeed, that target (as identified by the IP address and port number) SHOULD be ignored from the result set of any subsequent executions of the discovery algorithm at least until the target's Effective TTL (see Section 3.3) has expired or until the entity that executes the algorithm changes its TLS context to either send a new client certificate or expect a different server certificate.
発見されたターゲットへのTLSセッションのセットアップが成功しない場合、そのターゲット（IPアドレスとポート番号で識別される）は、少なくともターゲットの有効なTTLになるまで、以降の発見アルゴリズムの実行の結果セットから無視されるべきです（を参照）。セクション3.3）が期限切れになるか、アルゴリズムを実行するエンティティがTLSコンテキストを変更して新しいクライアント証明書を送信するか、別のサーバー証明書を要求するまで。
After the algorithm in this document has been executed, a RADIUS/TLS session as per [RFC6614] is established. Since the discovery algorithm does not have provisions to establish confidential keying material between the RADIUS/TLS client (i.e., the server that executes the discovery algorithm) and the RADIUS/TLS server that was discovered, Pre-Shared Key (PSK) ciphersuites for TLS cannot be used in the subsequent TLS handshake. Only TLS ciphersuites using X.509 certificates can be used with this algorithm.
このドキュメントのアルゴリズムが実行された後、[RFC6614]によるRADIUS / TLSセッションが確立されます。検出アルゴリズムには、RADIUS / TLSクライアント（つまり、検出アルゴリズムを実行するサーバー）と検出されたRADIUS / TLSサーバーとの間に機密のキー情報を確立するためのプロビジョニングがないため、TLSの事前共有キー（PSK）暗号スイート後続のTLSハンドシェイクでは使用できません。このアルゴリズムで使用できるのは、X.509証明書を使用するTLS暗号スイートだけです。
There are numerous ways to define which certificates are acceptable for use in this context. This document defines one mandatory-to-implement mechanism that allows verification of whether the contacted host is authoritative for an NAI realm or not. It also gives one example of another mechanism that is currently in widespread deployment and one possible approach based on DNSSEC, which is yet unimplemented.
このコンテキストで使用できる証明書を定義する方法は多数あります。このドキュメントは、接続されたホストがNAIレルムに対して権限があるかどうかの検証を可能にする1つの必須から実装へのメカニズムを定義します。また、現在広く普及している別のメカニズムの1つの例と、まだ実装されていないDNSSECに基づく1つの可能なアプローチも示しています。
For the approaches that use trust roots (see the following two sections), a typical deployment will use a dedicated trust store for RADIUS/TLS certificate authorities, particularly a trust store that is independent from default "browser" trust stores. Often, this will be one or a few Certification Authorities (CAs), and they only issue certificates for the specific purpose of establishing RADIUS server-to-server trust. It is important not to trust a large set of CAs that operate outside the control of the roaming consortium, since their issuance of certificates with the properties important for authorization (such as NAIRealm and policyOID below) is difficult to verify. Therefore, clients SHOULD NOT be preconfigured with a list of known public CAs by the vendor or manufacturer. Instead, the clients SHOULD start off with an empty CA list. The addition of a CA SHOULD be done only when manually configured by an administrator.
信頼ルートを使用するアプローチ（次の2つのセクションを参照）の場合、一般的な展開では、RADIUS / TLS認証局専用の信頼ストア、特にデフォルトの「ブラウザ」信頼ストアから独立した信頼ストアを使用します。多くの場合、これは1つまたはいくつかの証明機関（CA）であり、RADIUSサーバー間の信頼を確立する特定の目的のためにのみ証明書を発行します。承認に重要なプロパティ（以下のNAIRealmやpolicyOIDなど）を含む証明書の発行は確認が難しいため、ローミングコンソーシアムの制御外で動作するCAの大規模なセットを信頼しないことが重要です。したがって、クライアントは、ベンダーまたは製造元による既知のパブリックCAのリストを事前に構成してはなりません（SHOULD NOT）。代わりに、クライアントは空のCAリストで開始する必要があります（SHOULD）。 CAの追加は、管理者が手動で構成した場合にのみ行う必要があります。
Verification of authority to provide Authentication, Authorization, and Accounting (AAA) services over RADIUS/TLS is a two-step process.
RADIUS / TLSを介した認証、承認、アカウンティング（AAA）サービスを提供する権限の確認は、2段階のプロセスです。
Step 1 is the verification of certificate well-formedness and validity as per [RFC5280] and whether it was issued from a root certificate that is deemed trustworthy by the RADIUS/TLS client.
ステップ1は、[RFC5280]による証明書の整形式性と有効性、およびRADIUS / TLSクライアントによって信頼できると見なされるルート証明書から発行されたかどうかの検証です。
Step 2 is to compare the value of the algorithm's variable "R" after the execution of step 3 of the discovery algorithm in Section 3.4.3 below (i.e., after a consortium name mangling but before conversion to a form usable by the name resolution library) to all values of the contacted RADIUS/TLS server's X.509 certificate property "subjectAlternativeName:otherName:NAIRealm" as defined in Section 2.2.
ステップ2は、以下のセクション3.4.3のディスカバリアルゴリズムのステップ3の実行後（つまり、コンソーシアムの名前の変換後、名前解決ライブラリで使用可能なフォームに変換する前）に、アルゴリズムの変数「R」の値を比較することです。 ）セクション2.2で定義されているように、接続されたRADIUS / TLSサーバーのX.509証明書プロパティ「subjectAlternativeName：otherName：NAIRealm」のすべての値に。
Verification of authority to provide AAA services over RADIUS/TLS is a two-step process.
RADIUS / TLSを介してAAAサービスを提供する権限の確認は、2段階のプロセスです。
Step 1 is the verification of certificate well-formedness and validity as per [RFC5280] and whether it was issued from a root certificate that is deemed trustworthy by the RADIUS/TLS client.
ステップ1は、[RFC5280]による証明書の整形式性と有効性、およびRADIUS / TLSクライアントによって信頼できると見なされるルート証明書から発行されたかどうかの検証です。
Step 2 is to compare the values of the contacted RADIUS/TLS server's X.509 certificate's extensions of type "Policy OID" to a list of configured acceptable Policy OIDs for the roaming consortium. If one of the configured OIDs is found in the certificate's Policy OID extensions, then the server is considered authorized; if there is no match, the server is considered unauthorized.
手順2は、接続されたRADIUS / TLSサーバーのX.509証明書のタイプ「ポリシーOID」の拡張の値を、ローミングコンソーシアムに構成された受け入れ可能なポリシーOIDのリストと比較することです。構成されたOIDの1つが証明書のポリシーOID拡張で見つかった場合、サーバーは許可されていると見なされます。一致しない場合、サーバーは無許可と見なされます。
This mechanism is inferior to the mandatory-to-implement mechanism in the previous section because all authorized servers are validated by the same OID value; the mechanism is not fine grained enough to express authority for one specific realm inside the consortium. If the consortium contains members that are hostile against other members, this weakness can be exploited by one RADIUS/TLS server impersonating another if DNS responses can be spoofed by the hostile member.
このメカニズムは、許可されたすべてのサーバーが同じOID値によって検証されるため、前のセクションの「必須から実装」のメカニズムよりも劣ります。このメカニズムは、コンソーシアム内の特定の領域に対する権限を表現するのに十分な粒度ではありません。コンソーシアムに他のメンバーに対して敵対的なメンバーが含まれている場合、DNS応答が敵対的なメンバーによってなりすまされる可能性がある場合、この脆弱性は1つのRADIUS / TLSサーバーが別の偽装サーバーによって悪用される可能性があります。
The shortcomings in server identification can be partially mitigated by using the RADIUS infrastructure only with authentication payloads that provide mutual authentication and credential protection (i.e., Extensible Authentication Protocol (EAP) types passing the criteria of [RFC4017]): using mutual authentication prevents the hostile server from mimicking the real EAP server (it can't terminate the EAP authentication unnoticed because it does not have the server certificate from the real EAP server); protection of credentials prevents the impersonating server from learning usernames and passwords of the ongoing EAP conversation (other RADIUS attributes pertaining to the authentication, such as the EAP peer's Calling-Station-ID, can still be learned though).
サーバー識別の欠点は、相互認証と資格情報保護を提供する認証ペイロード（つまり、[RFC4017]の基準を満たすExtensible Authentication Protocol（EAP）タイプ）のみでRADIUSインフラストラクチャを使用することによって部分的に軽減できます：相互認証を使用すると、悪意を防ぎますサーバーが実際のEAPサーバーを模倣しないようにします（実際のEAPサーバーからのサーバー証明書がないため、気付かれずにEAP認証を終了できません）。資格情報の保護は、偽装サーバーが進行中のEAP会話のユーザー名とパスワードを学習するのを防ぎます（ただし、EAPピアのCalling-Station-IDなど、認証に関連する他のRADIUS属性は引き続き学習できます）。
Where DNSSEC is used, the results of the algorithm can be trusted; that is, the entity that executes the algorithm can be certain that the realm that triggered the discovery is actually served by the server that was discovered via DNS. However, this does not guarantee that the server is also authorized (i.e., a recognized member of the roaming consortium). The server still needs to present an X.509 certificate proving its authority to serve a particular realm.
DNSSECが使用されている場合、アルゴリズムの結果は信頼できます。つまり、アルゴリズムを実行するエンティティは、ディスカバリーをトリガーしたレルムが、DNSを介してディスカバーされたサーバーによって実際に提供されていることを確認できます。ただし、これはサーバーも承認されている（つまり、ローミングコンソーシアムの承認されたメンバーである）ことを保証するものではありません。サーバーは、特定のレルムを提供する権限を証明するX.509証明書を提示する必要があります。
The authorization can be sketched using DNSSEC and DNS-Based Authentication of Named Entities (DANE) as follows: DANE/TLSA records of all authorized servers are put into a DNSSEC zone that contains all known and authorized realms; the zone is rooted in a common, consortium-agreed branch of the DNS tree. The entity executing the algorithm uses the realm information from the authentication attempt and then attempts to retrieve TLSA resource records (TLSA RRs) for the DNS label "realm.commonroot". It then verifies that the presented server certificate during the RADIUS/TLS handshake matches the information in the TLSA record.
承認は、次のようにDNSSECおよび名前付きエンティティのDNSベースの認証（DANE）を使用してスケッチできます。すべての承認済みサーバーのDANE / TLSAレコードは、すべての既知の承認済みレルムを含むDNSSECゾーンに配置されます。ゾーンはDNSツリーの共通のコンソーシアム合意ブランチに根ざしています。アルゴリズムを実行するエンティティは、認証試行からのレルム情報を使用してから、DNSラベル「realm.commonroot」のTLSAリソースレコード（TLSA RR）を取得しようとします。次に、RADIUS / TLSハンドシェイク中に提示されたサーバー証明書がTLSAレコードの情報と一致することを確認します。
Example:
例：
Realm = "example.com"
レルム= "example.com"
Common Branch = "idp.roaming-consortium.example.
Common Branch = "idp.roaming-consortium.example。
label for TLSA query = "example.com.idp.roaming-consortium.example.
TLSAクエリのラベル= "example.com.idp.roaming-consortium.example。
result of discovery algorithm for realm "example.com" = 192.0.2.1:2083
レルム「example.com」の検出アルゴリズムの結果= 192.0.2.1:2083
( TLS certificate of 192.0.2.1:2083 matches TLSA RR ? "PASS" : "FAIL" )
（192.0.2.1:2083のTLS証明書はTLSA RRに一致しますか？ "PASS"： "FAIL"）
Note that RADIUS/TLS connections always mutually authenticate the RADIUS server and the RADIUS client. This specification provides an algorithm for a RADIUS client to contact and verify authorization of a RADIUS server only. During connection setup, the RADIUS server also needs to verify whether it considers the connecting RADIUS client authorized; this is outside the scope of this specification.
RADIUS / TLS接続は、常にRADIUSサーバーとRADIUSクライアントを相互に認証することに注意してください。この仕様は、RADIUSクライアントがRADIUSサーバーのみにアクセスして認証を検証するためのアルゴリズムを提供します。接続のセットアップ中に、RADIUSサーバーは、接続しているRADIUSクライアントを承認済みと見なすかどうかも確認する必要があります。これはこの仕様の範囲外です。
This specification defines two SRV prefixes (i.e., two values for the "_service._proto" part of an SRV RR as per [RFC2782]):
この仕様は、2つのSRVプレフィックスを定義します（つまり、[RFC2782]に従って、SRV RRの「_service._proto」部分の2つの値）。
+-------------------+-----------------------------------------+
| SRV Label | Use |
+-------------------+-----------------------------------------+
| _radiustls._tcp | RADIUS transported over TLS as defined |
| | in [RFC6614] |
| - - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
| _radiusdtls._udp | RADIUS transported over DTLS as defined |
| | in [RFC7360] |
+-------------------+-----------------------------------------+
Figure 5: List of SRV Labels
図5：SRVラベルのリスト
Just like NAPTR records, the lookup and subsequent follow up of SRV records may yield more than one server to contact in a prioritized list. [RFC2782] does not specify rules regarding "Definition of Conditions for Retry/Failure" nor "Server Identification and Handshake". This specification states that the rules for these two topics as defined in Sections 2.1.1.2 and 2.1.1.3 SHALL be used both for targets retrieved via an initial NAPTR RR as well as for targets retrieved via an initial SRV RR (i.e., in the absence of NAPTR RRs).
NAPTRレコードと同様に、SRVレコードのルックアップとその後のフォローアップでは、優先リストで連絡する複数のサーバーが生成される場合があります。 [RFC2782]は、「再試行/失敗の条件の定義」や「サーバーの識別とハンドシェイク」に関するルールを指定していません。この仕様では、セクション2.1.1.2および2.1.1.3で定義されているこれら2つのトピックのルールは、初期NAPTR RRを介して取得されたターゲットと、初期SRV RRを介して取得されたターゲットの両方に使用する必要がある（つまり、不在の場合） NAPTR RR）。
It is expected that in most cases, the SRV and/or NAPTR label used for the records is the DNS A-label representation of the literal realm name for which the server is the authoritative RADIUS server (i.e., the realm name after conversion according to Section 5 of [RFC5891]).
ほとんどの場合、レコードに使用されるSRVおよび/またはNAPTRラベルは、サーバーが権限のあるRADIUSサーバーであるリテラルレルム名のDNS Aラベル表現であることが期待されます（つまり、変換後のレルム名[RFC5891]のセクション5）。
However, arbitrary other labels or service tags may be used if, for example, a roaming consortium uses realm names that are not associated to DNS names or special-purpose consortia where a globally valid discovery is not a use case. Such other labels require a consortium-wide agreement about the transformation from realm name to lookup label and/or which service tag to use.
ただし、たとえば、ローミングコンソーシアムがDNS名に関連付けられていないレルム名を使用したり、グローバルに有効なディスカバリがユースケースではない特別な目的のコンソーシアムを使用したりする場合は、他の任意のラベルまたはサービスタグを使用できます。そのような他のラベルには、レルム名からルックアップラベルへの変換、および/または使用するサービスタグに関するコンソーシアム全体の合意が必要です。
Examples:
例：
a. A general-purpose RADIUS server for realm example.com might have DNS entries as follows:
a. レルムexample.comの汎用RADIUSサーバーには、次のようなDNSエントリがあります。
example.com. IN NAPTR 50 50 "s" "aaa+auth:radius.tls.tcp" "" _radiustls._tcp.foobar.example.com.
example.com。 IN NAPTR 50 50 "s" "aaa + auth：radius.tls.tcp" "" _radiustls._tcp.foobar.example.com。
_radiustls._tcp.foobar.example.com. IN SRV 0 10 2083 radsec.example.com.
_radiustls._tcp.foobar.example.com。 IN SRV 0 10 2083 radsec.example.com。
b. The consortium "foo" provides roaming services for its members only. The realms used are of the form enterprise-name.example. The consortium operates a special purpose DNS server for the (private) TLD "example", which all RADIUS servers use to resolve realm names. "Company, Inc." is part of the consortium. On the consortium's DNS server, realm company.example might have the following DNS entries:
b. コンソーシアム「foo」は、メンバーのみにローミングサービスを提供します。使用されるレルムの形式は、enterprise-name.exampleです。コンソーシアムは、（プライベート）TLDの「例」のために特別な目的のDNSサーバーを運用しています。これは、すべてのRADIUSサーバーがレルム名の解決に使用します。 「株式会社」コンソーシアムの一部です。コンソーシアムのDNSサーバーでは、レルムcompany.exampleに次のDNSエントリがある場合があります。
company.example. IN NAPTR 50 50 "a" "aaa+auth:radius.dtls.udp" "" roamserv.company.example.
company.example。 IN NAPTR 50 50 "a" "aaa + auth：radius.dtls.udp" "" roamserv.company.example。
c. The eduroam consortium (see [RFC7593]) uses realms based on DNS but provides its services to a closed community only. However, a AAA domain participating in eduroam may also want to expose AAA services to other, general-purpose, applications (on the same or other RADIUS servers). Due to that, the eduroam consortium uses the service tag "x-eduroam" for authentication purposes and eduroam RADIUS servers use this tag to look up other eduroam servers. An eduroam participant example.org that also provides general-purpose AAA on a different server uses the general "aaa+auth" tag:
c. eduroamコンソーシアム（[RFC7593]を参照）は、DNSに基づくレルムを使用しますが、そのサービスを閉じたコミュニティにのみ提供します。ただし、eduroamに参加しているAAAドメインは、AAAサービスを他の汎用アプリケーション（同じまたは他のRADIUSサーバー上）に公開することもできます。そのため、eduroamコンソーシアムは認証目的でサービスタグ「x-eduroam」を使用し、eduroam RADIUSサーバーはこのタグを使用して他のeduroamサーバーを検索します。別のサーバーで汎用AAAも提供するeduroam参加者example.orgは、一般的な「aaa + auth」タグを使用します。
example.org. IN NAPTR 50 50 "s" "x-eduroam:radius.tls.tcp" "" _radiustls._tcp.eduroam.example.org.
example.org。 IN NAPTR 50 50 "s" "x-eduroam：radius.tls.tcp" "" _radiustls._tcp.eduroam.example.org。
example.org. IN NAPTR 50 50 "s" "aaa+auth:radius.tls.tcp" "" _radiustls._tcp.aaa.example.org.
example.org。 IN NAPTR 50 50 "s" "aaa + auth：radius.tls.tcp" "" _radiustls._tcp.aaa.example.org。
_radiustls._tcp.eduroam.example.org. IN SRV 0 10 2083 aaa-eduroam.example.org.
_radiustls._tcp.eduroam.example.org。 IN SRV 0 10 2083 aaa-eduroam.example.org。
_radiustls._tcp.aaa.example.org. IN SRV 0 10 2083 aaa-default.example.org.
_radiustls._tcp.aaa.example.org。 IN SRV 0 10 2083 aaa-default.example.org。
2.2. Definition of the X.509 Certificate Property SubjectAltName:otherName:NAIRealm
2.2. X.509証明書プロパティSubjectAltName：otherName：NAIRealmの定義
This specification retrieves IP addresses and port numbers from the Domain Name System that are subsequently used to authenticate users via the RADIUS/TLS protocol. Regardless whether the results from DNS discovery are trustworthy or not (e.g., DNSSEC in use), it is always important to verify that the server that was contacted is authorized to service requests for the user that triggered the discovery process.
この仕様は、ドメインネームシステムからIPアドレスとポート番号を取得し、RADIUS / TLSプロトコルを介してユーザーを認証するために後で使用されます。 DNS検出の結果が信頼できるかどうか（DNSSECが使用されているなど）に関係なく、接続されたサーバーが、検出プロセスをトリガーしたユーザーの要求にサービスを提供する権限があることを確認することは常に重要です。
The input to the algorithm is an NAI realm as specified in Section 3.4.1. As a consequence, the X.509 certificate of the server that is ultimately contacted for user authentication needs to be able to express that it is authorized to handle requests for that realm.
アルゴリズムへの入力は、セクション3.4.1で指定されているNAIレルムです。その結果、ユーザー認証のために最終的に接続されるサーバーのX.509証明書は、そのレルムの要求を処理する権限があることを表現できる必要があります。
Current subjectAltName fields do not semantically allow an NAI realm to be expressed; the field subjectAltName:dNSName is syntactically a good match but would inappropriately conflate DNS names and NAI realm names. Thus, this specification defines a new subjectAltName field to hold either a single NAI realm name or a wildcard name matching a set of NAI realms.
現在のsubjectAltNameフィールドでは、意味的にNAIレルムを表現できません。 subjectAltName：dNSNameフィールドは構文的には適切に一致しますが、DNS名とNAIレルム名を不適切に統合します。したがって、この仕様では、単一のNAIレルム名または一連のNAIレルムと一致するワイルドカード名のいずれかを保持する新しいsubjectAltNameフィールドを定義しています。
The subjectAltName:otherName:sRVName field certifies that a certificate holder is authorized to provide a service; this can be compared to the target of a DNS label's SRV resource record. If the Domain Name System is insecure, it is required that the label of the SRV record itself is known-correct. In this specification, that label is not known-correct; it is potentially derived from a (potentially untrusted) NAPTR resource record of another label. If DNS is not secured with DNSSEC, the NAPTR resource record may have been altered by an attacker with access to the Domain Name System resolution, and thus the label used to look up the SRV record may already be tainted. This makes subjectAltName:otherName:sRVName not a trusted comparison item.
subjectAltName：otherName：sRVNameフィールドは、証明書所有者がサービスを提供することを承認されていることを証明します。これは、DNSラベルのSRVリソースレコードのターゲットと比較できます。ドメインネームシステムが安全でない場合は、SRVレコード自体のラベルが正しいことが必要です。この仕様では、そのラベルは既知の正しいものではありません。別のラベルの（潜在的に信頼できない）NAPTRリソースレコードから派生した可能性があります。 DNSがDNSSECで保護されていない場合、NAPTRリソースレコードは、ドメインネームシステムの解決へのアクセス権を持つ攻撃者によって変更されている可能性があり、SRVレコードの検索に使用されるラベルはすでに汚染されている可能性があります。これにより、subjectAltName：otherName：sRVNameは信頼できる比較アイテムではなくなります。
Further to this, this specification's NAPTR entries may be of type "A", which does not involve resolution of any SRV records, which again makes subjectAltName:otherName:sRVName unsuited for this purpose.
さらに、この仕様のNAPTRエントリはタイプ「A」である可能性があり、SRVレコードの解決を含まないため、subjectAltName：otherName：sRVNameはこの目的には適していません。
This section defines the NAIRealm name as a form of otherName from the GeneralName structure in subjectAltName defined in [RFC5280].
このセクションは、[RFC5280]で定義されたsubjectAltNameのGeneralName構造からのotherNameの形式としてNAIRealm名を定義します。
id-on-naiRealm OBJECT IDENTIFIER ::= { id-on 8 }
ub-naiRealm-length INTEGER ::= 255
NAIRealm ::= UTF8String (SIZE (1..ub-naiRealm-length))
The NAIRealm, if present, MUST contain an NAI realm as defined in [RFC7542]. It MAY substitute the leftmost dot-separated label of the NAI with the single character "*" to indicate a wildcard match for "all labels in this part". Further features of regular expressions, such as a number of characters followed by an "*" to indicate a common prefix inside the part, are not permitted.
NAIRealmが存在する場合は、[RFC7542]で定義されているNAIレルムを含める必要があります。 NAIの左端のドットで区切られたラベルを単一文字「*」に置き換えて、「この部分のすべてのラベル」のワイルドカード一致を示す場合があります。一部の文字の後に「*」が付いてパーツ内の共通の接頭辞を示すなど、正規表現のその他の機能は許可されません。
The comparison of an NAIRealm to the NAI realm as derived from user input with this algorithm is a byte-by-byte comparison, except for the optional leftmost dot-separated part of the value whose content is a single "*" character; such labels match all strings in the same dot-separated part of the NAI realm. If at least one of the sAN:otherName:NAIRealm values match the NAI realm, the server is considered authorized; if none match, the server is considered unauthorized.
このアルゴリズムを使用したユーザー入力から導出されたNAIRealmとNAIレルムの比較は、バイト単位の比較です。ただし、値の左端にあるドットで区切られた部分は、単一の「*」文字です。このようなラベルは、NAIレルムの同じドットで区切られた部分にあるすべての文字列に一致します。 sAN：otherName：NAIRealm値の少なくとも1つがNAIレルムと一致する場合、サーバーは承認されたと見なされます。一致するものがない場合、サーバーは無許可と見なされます。
Since multiple names and multiple name forms may occur in the subjectAltName extension, an arbitrary number of NAIRealms can be specified in a certificate.
subjectAltName拡張で複数の名前と複数の名前形式が発生する可能性があるため、証明書で任意の数のNAIRealmsを指定できます。
Examples:
例：
+---------------------+-------------------+-----------------------+
| NAI realm (RADIUS) | NAIRealm (cert) | MATCH? |
+---------------------+-------------------+-----------------------+
| foo.example | foo.example | YES |
| foo.example | *.example | YES |
| bar.foo.example | *.example | NO |
| bar.foo.example | *ar.foo.example | NO (NAIRealm invalid) |
| bar.foo.example | bar.*.example | NO (NAIRealm invalid) |
| bar.foo.example | *.*.example | NO (NAIRealm invalid) |
| sub.bar.foo.example | *.*.example | NO (NAIRealm invalid) |
| sub.bar.foo.example | *.bar.foo.example | YES |
+-----------------+-----------------------------------------------+
Figure 6: Examples for NAI Realm vs. Certificate Matching
図6：NAIレルムと証明書の照合の例
Appendix A contains the ASN.1 definition of the above objects.
付録Aには、上記のオブジェクトのASN.1定義が含まれています。
Dynamic server discovery as defined in this document is only applicable for new AAA transactions and per service (i.e., distinct discovery is needed for Authentication, Accounting, and Dynamic Authorization) where a RADIUS entity that acts as a forwarding server for one or more realms receives a request with a realm for which it is not authoritative, and which no explicit next hop is configured. It is only applicable for
このドキュメントで定義されている動的サーバー検出は、新しいAAAトランザクションとサービスごとにのみ適用されます（つまり、1つ以上のレルムの転送サーバーとして機能するRADIUSエンティティが受信する、認証、アカウンティング、および動的承認には別個の検出が必要です）。権限がなく、明示的なネクストホップが構成されていないレルムを持つ要求。のみに適用されます
a. new user sessions, i.e., for the initial Access-Request. Subsequent messages concerning this session, for example, Access-Challenges and Access-Accepts, use the previously established communication channel between client and server.
a. 新しいユーザーセッション、つまり最初のAccess-Request。このセッションに関する後続のメッセージ（Access-ChallengesやAccess-Acceptsなど）は、クライアントとサーバー間で以前に確立された通信チャネルを使用します。
b. the first accounting ticket for a user session.
b. ユーザーセッションの最初のアカウンティングチケット。
c. the first RADIUS DynAuth packet for a user session.
c. ユーザーセッションの最初のRADIUS DynAuthパケット。
The algorithm contains various variables for timeouts. These variables are named here and reasonable default values are provided. Implementations wishing to deviate from these defaults should make sure they understand the implications of changes.
アルゴリズムには、タイムアウトのさまざまな変数が含まれています。これらの変数の名前はここにあり、適切なデフォルト値が提供されています。これらのデフォルトから逸脱したい実装は、変更の影響を確実に理解する必要があります。
DNS_TIMEOUT: maximum amount of time to wait for the complete set of all DNS queries to complete: Default = 3 seconds
DNS_TIMEOUT：すべてのDNSクエリの完全なセットが完了するまで待機する最大時間：デフォルト= 3秒
MIN_EFF_TTL: minimum DNS TTL of discovered targets: Default = 60 seconds
MIN_EFF_TTL：検出されたターゲットの最小DNS TTL：デフォルト= 60秒
BACKOFF_TIME: if no conclusive DNS response was retrieved after DNS_TIMEOUT, do not attempt dynamic discovery before BACKOFF_TIME has elapsed: Default = 600 seconds
BACKOFF_TIME：DNS_TIMEOUTの後に決定的なDNS応答が取得されなかった場合は、BACKOFF_TIMEが経過するまで動的検出を試行しないでください。デフォルト= 600秒
Positive DNS response: A response that contains the RR that was queried for.
正のDNS応答：照会されたRRを含む応答。
Negative DNS response: A response that does not contain the RR that was queried for but contains an SOA record along with a TTL indicating cache duration for this negative result.
否定的なDNS応答：照会されたRRを含まないが、この否定的な結果のキャッシュ期間を示すTTLと共にSOAレコードを含む応答。
DNS Error: Where the algorithm states "name resolution returns with an error", this shall mean that either the DNS request timed out or it is a DNS response, which is neither a positive nor a negative response (e.g., SERVFAIL).
DNSエラー：アルゴリズムが「名前解決がエラーで戻る」と述べている場合、これはDNS要求がタイムアウトしたか、それがDNS応答であり、肯定応答でも否定応答でもないことを意味します（SERVFAILなど）。
Effective TTL: The validity period for discovered RADIUS/TLS target
hosts. Calculated as: Effective TTL (set of DNS TTL values) = max {
MIN_EFF_TTL, min { DNS TTL values } }
SRV lookup: For the purpose of this specification, SRV lookup procedures are defined as per [RFC2782] but excluding that RFCs "A" fallback as defined in the "Usage Rules" section, final "else" clause.
SRVルックアップ：この仕様では、SRVルックアップ手順は[RFC2782]で定義されていますが、「使用規則」セクションの最後の「else」節で定義されているRFC「A」のフォールバックは除外されています。
Greedy result evaluation: The NAPTR to SRV/A/AAAA resolution may lead to a tree of results, whose leafs are the IP addresses to contact. The branches of the tree are ordered according to their order/ preference DNS properties. An implementation is executing greedy result evaluation if it uses a depth-first search in the tree along the highest order results, attempts to connect to the corresponding resulting IP addresses, and only backtracks to other branches if the higher ordered results did not end in successful connection attempts.
貪欲な結果の評価：NAPTRからSRV / A / AAAAへの解決は、結果のツリーにつながる可能性があり、そのリーフは連絡先のIPアドレスです。ツリーのブランチは、その順序/優先DNSプロパティに従って順序付けられます。実装は、最上位の結果に沿ってツリーで縦型検索を使用し、対応する結果のIPアドレスへの接続を試み、より高い順序の結果が成功しない場合にのみ他のブランチにバックトラックする場合、貪欲な結果評価を実行しています。接続試行。
For RADIUS Authentication and RADIUS Accounting server discovery, input I to the algorithm is the RADIUS User-Name attribute with content of the form "user@realm"; the literal "@" sign is the separator between a local user identifier within a realm and its realm. The use of multiple literal "@" signs in a User-Name is strongly discouraged; but if present, the last "@" sign is to be considered the separator. All previous instances of the "@" sign are to be considered part of the local user identifier.
RADIUS認証およびRADIUSアカウンティングサーバーの検出の場合、アルゴリズムへの入力Iは、 "user @ realm"という形式のコンテンツを持つRADIUSユーザー名属性です。リテラル「@」記号は、レルム内のローカルユーザー識別子とそのレルムの間の区切り文字です。ユーザー名で複数のリテラル "@"記号を使用することは強くお勧めしません。ただし、存在する場合、最後の「@」記号は区切り文字と見なされます。以前の「@」記号はすべて、ローカルユーザー識別子の一部と見なされます。
For RADIUS DynAuth server discovery, input I to the algorithm is the domain name of the operator of a RADIUS realm as was communicated during user authentication using the Operator-Name attribute ([RFC5580], Section 4.1). Only Operator-Name values with the namespace "1" are supported by this algorithm -- the input to the algorithm is the actual domain name, preceded with an "@" (but without the "1" namespace identifier byte of that attribute).
RADIUS DynAuthサーバー検出の場合、アルゴリズムへの入力Iは、オペレーター名属性を使用したユーザー認証中に通信されたRADIUSレルムのオペレーターのドメイン名です（[RFC5580]、セクション4.1）。このアルゴリズムでは、名前空間「1」のOperator-Name値のみがサポートされています。アルゴリズムへの入力は、「@」が前に付いた実際のドメイン名です（ただし、その属性の「1」名前空間識別子バイトはありません）。
Note well: The attribute User-Name is defined to contain UTF-8 text. In practice, the content may or may not be UTF-8. Even if UTF-8, it may or may not map to a domain name in the realm part. Implementors MUST take possible conversion error paths into consideration when parsing incoming User-Name attributes. This document describes server discovery only for well-formed realms mapping to DNS domain names in UTF-8 encoding. The result of all other possible contents of User-Name is unspecified; this includes, but is not limited to:
注：属性User-Nameは、UTF-8テキストを含むように定義されています。実際には、コンテンツはUTF-8である場合とそうでない場合があります。 UTF-8であっても、レルム部分のドメイン名にマップする場合としない場合があります。実装者は、着信するユーザー名属性を解析するときに、考えられる変換エラーパスを考慮する必要があります。このドキュメントでは、UTF-8エンコーディングでDNSドメイン名にマッピングされた正しい形式のレルムのみのサーバー検出について説明します。 User-Nameの他の可能なすべてのコンテンツの結果は指定されていません。これには以下が含まれますが、これらに限定されません。
Usage of separators other than "@".
「@」以外の区切り文字の使用。
Encoding of User-Name in local encodings.
ローカルエンコーディングでのユーザー名のエンコーディング。
UTF-8 realms that fail the conversion rules as per [RFC5891].
[RFC5891]による変換ルールに失敗するUTF-8レルム。
UTF-8 realms that end with a "." ("dot") character.
「。」で終わるUTF-8レルム（「ドット」）文字。
For the last bullet point, "trailing dot", special precautions should be taken to avoid problems when resolving servers with the algorithm below: they may resolve to a RADIUS server even if the peer RADIUS server only is configured to handle the realm without the trailing dot. If that RADIUS server again uses NAI discovery to determine the authoritative server, the server will forward the request to localhost, resulting in a tight endless loop.
最後の箇条書き「末尾のドット」については、以下のアルゴリズムでサーバーを解決する際の問題を回避するために特別な予防措置を講じる必要があります。ピアRADIUSサーバーのみが末尾なしでレルムを処理するように構成されている場合でも、RADIUSサーバーに解決される場合があります。ドット。そのRADIUSサーバーが再びNAIディスカバリーを使用して権限のあるサーバーを判別すると、サーバーは要求をlocalhostに転送し、結果としてタイトなエンドレスループが発生します。
Output O of the algorithm is a two-tuple consisting of: O-1) a set of tuples {hostname; port; protocol; order/preference; Effective TTL} -- the set can be empty -- and O-2) an integer. If the set in the first part of the tuple is empty, the integer contains the Effective TTL for backoff timeout; if the set is not empty, the integer is set to 0 (and not used).
アルゴリズムの出力Oは、次の2つのタプルで構成されます。O-1）タプルのセット{ホスト名;港;プロトコル;注文/好み;有効なTTL}-セットは空にすることができます-およびO-2）整数。タプルの最初の部分のセットが空の場合、整数にはバックオフタイムアウトの有効なTTLが含まれます。セットが空でない場合、整数は0に設定されます（使用されません）。
The algorithm to determine the RADIUS server to contact is as follows:
接続するRADIUSサーバーを決定するアルゴリズムは次のとおりです。
1. Determine P = (position of last "@" character) in I.
1. IのP =（最後の "@"文字の位置）を決定します。
2. Generate R = (substring from P+1 to end of I).
2. R =（P + 1からIの終わりまでの部分文字列）を生成します。
3. Modify R according to agreed consortium procedures if applicable.
3. 必要に応じて、合意されたコンソーシアムの手順に従ってRを変更します。
4. Convert R to a representation usable by the name resolution library if needed.
4. 必要に応じて、Rを名前解決ライブラリで使用可能な表現に変換します。
5. Initialize TIMER = 0; start TIMER. If TIMER reaches DNS_TIMEOUT, continue at step 20.
5. TIMER = 0を初期化します。タイマーを開始します。 TIMERがDNS_TIMEOUTに達した場合は、手順20に進みます。
6. Using the host's name resolution library, perform a NAPTR query for R (see "Delay Considerations", Section 3.4.5, below). If the result is a negative DNS response, O-2 = Effective TTL ( TTL value of the SOA record ) and continue at step 13. If name resolution returns with error, O-1 = { empty set }, O-2 = BACKOFF_TIME, and terminate.
6. ホストの名前解決ライブラリを使用して、RのNAPTRクエリを実行します（「遅延に関する考慮事項」のセクション3.4.5を参照）。結果がDNS否定応答の場合、O-2 =有効なTTL（SOAレコードのTTL値）で、ステップ13に進みます。名前解決がエラーで返された場合、O-1 = {空のセット}、O-2 = BACKOFF_TIME 、終了します。
7. Extract NAPTR records with service tags "aaa+auth", "aaa+acct", and "aaa+dynauth" as appropriate. Keep note of the protocol tag and remaining TTL of each of the discovered NAPTR records.
7. 必要に応じて、サービスタグ「aaa + auth」、「aaa + acct」、および「aaa + dynauth」でNAPTRレコードを抽出します。検出された各NAPTRレコードのプロトコルタグと残りのTTLをメモしておきます。
8. If no records are found, continue at step 13.
8. レコードが見つからない場合は、手順13に進みます。
9. For the extracted NAPTRs, perform successive resolution as defined in [RFC3958], Section 2.2. An implementation MAY use greedy result evaluation according to the NAPTR order/preference fields (i.e., can execute the subsequent steps of this algorithm for the highest-order entry in the set of results and only look up the remainder of the set if necessary).
9. 抽出されたNAPTRについて、[RFC3958]、セクション2.2で定義されているように、連続解決を実行します。実装は、NAPTR順序/優先フィールドに従って貪欲な結果評価を使用できます（つまり、結果のセットの最高次のエントリに対してこのアルゴリズムの後続のステップを実行し、必要に応じてセットの残りの部分のみを検索できます）。
10. If the set of hostnames is empty, O-1 = { empty set }, O-2 = BACKOFF_TIME, and terminate.
10. ホスト名のセットが空の場合、O-1 = {空のセット}、O-2 = BACKOFF_TIMEで終了します。
11. O' = (set of {hostname; port; protocol; order/preference; Effective TTL ( all DNS TTLs that led to this hostname ) } for all terminal lookup results).
11. O '=（{ホスト名;ポート;プロトコル;順序/設定;有効なTTLのセット（このホスト名につながったすべてのDNS TTL）}すべての端末ルックアップ結果）。
12. Proceed with step 18.
12. ステップ18に進みます。
13. Generate R' = (prefix R with "_radiustls._tcp." and/or "_radiustls._udp.").
13. R '=（Rの前に "_radiustls._tcp。"や "_radiustls._udp。"を付ける）を生成します。
14. Using the host's name resolution library, perform SRV lookup with R' as label (see "Delay Considerations", Section 3.4.5, below).
14. ホストの名前解決ライブラリを使用して、R 'をラベルとしてSRV検索を実行します（以下の「遅延に関する考慮事項」のセクション3.4.5を参照）。
15. If name resolution returns with error, O-1 = { empty set }, O-2 = BACKOFF_TIME, and terminate.
15. 名前解決がエラーで戻る場合、O-1 = {空のセット}、O-2 = BACKOFF_TIMEで終了します。
16. If the result is a negative DNS response, O-1 = { empty set }, O-2 = min { O-2, Effective TTL ( TTL value of the SOA record ) }, and terminate.
16. 結果がDNS否定応答の場合、O-1 = {空のセット}、O-2 =最小{O-2、有効なTTL（SOAレコードのTTL値）}で終了します。
17. O' = (set of {hostname; port; protocol; order/preference; Effective TTL ( all DNS TTLs that led to this result ) } for all hostnames).
17. O '=（{ホスト名のセット;ポート;プロトコル;順序/設定;有効なTTL（この結果の原因となったすべてのDNS TTL）}すべてのホスト名）。
18. Generate O-1 by resolving hostnames in O' into corresponding A and/or AAAA addresses: O-1 = (set of {IP address; port; protocol; order/preference; Effective TTL ( all DNS TTLs that led to this result ) } for all hostnames ), O-2 = 0.
18. O 'のホスト名を対応するAおよび/またはAAAAアドレスに解決してO-1を生成します。O-1=（{IPアドレスのセット;ポート;プロトコル;順序/設定;有効なTTL（この結果に至ったすべてのDNS TTL）） }（すべてのホスト名）、O-2 = 0。
19. For each element in O-1, test if the original request that triggered dynamic discovery was received on {IP address; port}. If yes, O-1 = { empty set }, O-2 = BACKOFF_TIME, log error, and terminate (see next section for a rationale). If no, O is the result of dynamic discovery; terminate.
19. O-1の各要素について、動的検出をトリガーした元の要求が{IPアドレス;港}。はいの場合、O-1 = {空のセット}、O-2 = BACKOFF_TIME、エラーをログに記録して終了します（理由については次のセクションを参照）。いいえの場合、Oは動的発見の結果です。終了します。
20. O-1 = { empty set }, O-2 = BACKOFF_TIME, log error, and terminate.
20. O-1 = {空のセット}、O-2 = BACKOFF_TIME、エラーをログに記録して終了します。
The discovery algorithm is used by servers that do not have sufficient configuration information to process an incoming request on their own. If the discovery algorithm result contains the server's own listening address (IP address and port), then there is a potential for an endless forwarding loop. If the listening address is the DNS result with the highest priority, the server will enter a tight loop (the server would forward the request to itself, triggering dynamic discovery again in a perpetual loop). If the address has a lower priority in the set of results, there is a potential loop with intermediate hops in between (the server could forward to another host with a higher priority, which might use DNS itself and forward the packet back to the first server). The underlying reason that enables these loops is that the server executing the discovery algorithm is seriously misconfigured in that it does not recognize the request as one that is to be processed by itself. RADIUS has no built-in loop detection, so any such loops would remain undetected. So, if step 18 of the algorithm discovers such a possible-loop situation, the algorithm should be aborted and an error logged. Note that this safeguard does not provide perfect protection against routing loops. One reason that might introduce a loop includes the possibility that a subsequent hop has a statically configured next hop that leads to an earlier host in the loop. Another reason for occurring loops is if the algorithm was executed with greedy result evaluation, and the server's own address was in a lower-priority branch of the result set that was not retrieved from DNS at all, and thus can't be detected.
検出アルゴリズムは、着信要求を自分で処理するのに十分な構成情報がないサーバーによって使用されます。検出アルゴリズムの結果にサーバー自体のリスニングアドレス（IPアドレスとポート）が含まれている場合は、無限の転送ループが発生する可能性があります。リスニングアドレスが優先度が最も高いDNS結果である場合、サーバーはタイトループに入ります（サーバーはリクエストを自身に転送し、永続的なループで動的検出をトリガーします）。結果のセットでアドレスの優先度が低い場合、中間ホップの間にループが発生する可能性があります（サーバーは優先度の高い別のホストに転送し、DNS自体を使用してパケットを最初のサーバーに転送します。 ）。これらのループを可能にする根本的な理由は、ディスカバリアルゴリズムを実行するサーバーが、リクエストをそれ自体で処理されるリクエストとして認識しないという点で、重大な設定が誤っているためです。 RADIUSにはループ検出機能が組み込まれていないため、このようなループは検出されません。したがって、アルゴリズムのステップ18でこのようなループの可能性がある状況が検出された場合、アルゴリズムを中止してエラーをログに記録する必要があります。このセーフガードはルーティングループに対して完全な保護を提供しないことに注意してください。ループが発生する可能性がある1つの理由として、後続のホップに静的に構成されたネクストホップがあり、ループ内のより早いホストにつながる可能性があります。ループが発生するもう1つの理由は、アルゴリズムが貪欲な結果評価で実行され、サーバー自体のアドレスが、DNSからまったく取得されなかった結果セットの優先順位の低いブランチにあり、検出されなかった場合です。
After executing the above algorithm, the RADIUS server establishes a connection to a home server from the result set. This connection can potentially remain open for an indefinite amount of time. This conflicts with the possibility of changing device and network configurations on the receiving end. Typically, TTL values for records in the name resolution system are used to indicate how long it is safe to rely on the results of the name resolution. If these TTLs are very low, thrashing of connections becomes possible; the Effective TTL mitigates that risk. When a connection is open and the smallest of the Effective TTL value that was learned during discovering the server has not expired, subsequent new user sessions for the realm that corresponds to that open connection SHOULD reuse the existing connection and SHOULD NOT re-execute the discovery algorithm nor open a new connection. To allow for a change of configuration, a RADIUS server SHOULD re-execute the discovery algorithm after the Effective TTL that is associated with this connection has expired. The server SHOULD keep the session open during this reassessment to avoid closure and immediate reopening of the connection should the result not have changed.
上記のアルゴリズムを実行した後、RADIUSサーバーは結果セットからホームサーバーへの接続を確立します。この接続は、無期限に開いたままになる可能性があります。これは、受信側でデバイスとネットワーク構成を変更する可能性と競合します。通常、名前解決システムのレコードのTTL値は、名前解決の結果に依存することが安全である期間を示すために使用されます。これらのTTLが非常に低い場合、接続のスラッシングが可能になります。有効なTTLはそのリスクを軽減します。接続が開いており、サーバーの検出中に学習された有効なTTL値の最小値が期限切れになっていない場合、その開いている接続に対応するレルムの後続の新しいユーザーセッションは、既存の接続を再利用し（SHOULD）、検出を再実行してはアルゴリズムも新しい接続も開きません。構成の変更を可能にするために、RADIUSサーバーは、この接続に関連付けられている有効なTTLが期限切れになった後で、検出アルゴリズムを再実行する必要があります（SHOULD）。サーバーは、結果が変更されていない場合に接続が閉じられてすぐに再開されるのを避けるために、この再評価中はセッションを開いたままにする必要があります（SHOULD）。
Should the algorithm above terminate with O-1 = { empty set }, the
RADIUS server SHOULD NOT attempt another execution of this algorithm
for the same target realm before the timeout O-2 has passed.
The host's name resolution library may need to contact outside entities to perform the name resolution (e.g., authoritative name servers for a domain), and since the NAI discovery algorithm is based on uncontrollable user input, the destination of the lookups is out of control of the server that performs NAI discovery. If such outside entities are misconfigured or unreachable, the algorithm above may need an unacceptably long time to terminate. Many RADIUS implementations time out after five seconds of delay between Request and Response. It is not useful to wait until the host name resolution library signals a timeout of its name resolution algorithms. The algorithm therefore controls execution time with TIMER. Execution of the NAI discovery algorithm SHOULD be non-blocking (i.e., allow other requests to be processed in parallel to the execution of the algorithm).
ホストの名前解決ライブラリは、名前解決を実行するために外部エンティティにアクセスする必要がある場合があります（たとえば、ドメインの信頼できるネームサーバー）。NAI検出アルゴリズムは制御できないユーザー入力に基づいているため、ルックアップの宛先は制御不能です。 NAIディスカバリーを実行するサーバー。このような外部エンティティが正しく構成されていない、または到達できない場合、上記のアルゴリズムが終了するのに許容できないほど長い時間が必要になる場合があります。多くのRADIUS実装は、要求と応答の間の5秒の遅延後にタイムアウトします。ホストの名前解決ライブラリが名前解決アルゴリズムのタイムアウトを通知するまで待つことは役に立ちません。したがって、アルゴリズムはTIMERを使用して実行時間を制御します。 NAIディスカバリアルゴリズムの実行はノンブロッキングである必要があります（つまり、他のリクエストをアルゴリズムの実行と並行して処理できるようにする必要があります）。
Assume
想定する
a user from the Technical University of Munich, Germany, has a RADIUS User-Name of "foobar@tu-m[U+00FC]nchen.example".
ドイツのミュンヘン工科大学のユーザーは、「foobar @ tu-m [U + 00FC] nchen.example」というRADIUSユーザー名を持っています。
The name resolution library on the RADIUS forwarding server does not have the realm tu-m[U+00FC]nchen.example in its forwarding configuration but uses DNS for name resolution and has configured the use of dynamic discovery to discover RADIUS servers.
RADIUS転送サーバー上の名前解決ライブラリの転送構成にはレルムtu-m [U + 00FC] nchen.exampleがありませんが、名前解決にDNSを使用し、動的検出を使用してRADIUSサーバーを検出するように構成しています。
It is IPv6 enabled and prefers AAAA records over A records.
IPv6対応で、AレコードよりもAAAAレコードを優先します。
It is listening for incoming RADIUS/TLS requests on 192.0.2.1, TCP/2083.
192.0.2.1、TCP / 2083で着信RADIUS / TLS要求をリッスンしています。
May the configuration variables be
構成変数が
DNS_TIMEOUT = 3 seconds
MIN_EFF_TTL = 60 seconds
BACKOFF_TIME = 3600 seconds
If DNS contains the following records
DNSに次のレコードが含まれている場合
xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s" "aaa+auth:radius.tls.tcp" "" _myradius._tcp.xn--tu-mnchen-t9a.example.
xn--tu-mnchen-t9a.example。 IN NAPTR 50 50 "s" "aaa + auth：radius.tls.tcp" "" _myradius._tcp.xn--tu-mnchen-t9a.example。
xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s" "fooservice:bar.dccp" "" _abc123._def.xn--tu-mnchen-t9a.example.
xn--tu-mnchen-t9a.example。 IN NAPTR 50 50 "s" "fooservice：bar.dccp" "" _abc123._def.xn--tu-mnchen-t9a.example。
_myradius._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 10 2083 radsecserver.xn--tu-mnchen-t9a.example.
_myradius._tcp.xn--tu-mnchen-t9a.example。 IN SRV 0 10 2083 radsecserver.xn--tu-mnchen-t9a.example。
_myradius._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 20 2083 backupserver.xn--tu-mnchen-t9a.example.
_myradius._tcp.xn--tu-mnchen-t9a.example。 IN SRV 0 20 2083 backupserver.xn--tu-mnchen-t9a.example。
radsecserver.xn--tu-mnchen-t9a.example. IN AAAA
2001:0DB8::202:44ff:fe0a:f704
radsecserver.xn--tu-mnchen-t9a.example. IN A 192.0.2.3
radsecserver.xn--tu-mnchen-t9a.example。 IN 192.0.2.3
backupserver.xn--tu-mnchen-t9a.example. IN A 192.0.2.7
backupserver.xn--tu-mnchen-t9a.example。 IN 192.0.2.7
Then the algorithm executes as follows, with I = "foobar@tu-m[U+00FC]nchen.example", and no consortium name mangling in use:
次に、アルゴリズムは次のように実行されます。I= "foobar @ tu-m [U + 00FC] nchen.example"で、コンソーシアム名のマングリングは使用されていません。
1. P = 7
1. P = 7
2. R = "tu-m[U+00FC]nchen.example"
2. R = "tu-m [U + 00FC] nchen.example"
3. NOOP
3. NOOP
4. Name resolution library converts R to xn--tu-mnchen-t9a.example
4. 名前解決ライブラリはRをxnに変換します--tu-mnchen-t9a.example
5. TIMER starts.
5. タイマーが始まります。
6. Result:
6. 結果：
(TTL = 47) 50 50 "s" "aaa+auth:radius.tls.tcp" "" _myradius._tcp.xn--tu-mnchen-t9a.example.
（TTL = 47）50 50 "s" "aaa + auth：radius.tls.tcp" "" _myradius._tcp.xn--tu-mnchen-t9a.example。
(TTL = 522) 50 50 "s" "fooservice:bar.dccp" "" _abc123._def.xn--tu-mnchen-t9a.example.
（TTL = 522）50 50 "s" "fooservice：bar.dccp" "" _abc123._def.xn--tu-mnchen-t9a.example。
7. Result:
7. 結果：
(TTL = 47) 50 50 "s" "aaa+auth:radius.tls.tcp" "" _myradius._tcp.xn--tu-mnchen-t9a.example.
（TTL = 47）50 50 "s" "aaa + auth：radius.tls.tcp" "" _myradius._tcp.xn--tu-mnchen-t9a.example。
8. NOOP
8. NOOP
9. Successive resolution performs SRV query for label _myradius._tcp.xn--tu-mnchen-t9a.example, which results in
9. 逐次解決により、ラベル_myradius._tcp.xn--tu-mnchen-t9a.exampleに対してSRVクエリが実行され、結果は
(TTL 499) 0 10 2083 radsec.xn--tu-mnchen-t9a.example.
（TTL 499）0 10 2083 radsec.xn--tu-mnchen-t9a.example。
(TTL 2200) 0 20 2083 backup.xn--tu-mnchen-t9a.example.
（TTL 2200）0 20 2083 backup.xn--tu-mnchen-t9a.example。
10. NOOP
10. NOOP
11. O' = {
11. お’ ＝ ｛
(radsec.xn--tu-mnchen-t9a.example.; 2083; RADIUS/TLS; 10; 60),
（radsec.xn--tu-mnchen-t9a.example .; 2083; RADIUS / TLS; 10; 60）、
(backup.xn--tu-mnchen-t9a.example.; 2083; RADIUS/TLS; 20; 60)
} // minimum TTL is 47, upped to MIN_EFF_TTL
12. Continuing at 18.
12. 18に進みます。
13. (not executed)
13. （実行されません）
14. (not executed)
14. （実行されません）
15. (not executed)
15. （実行されません）
16. (not executed)
16. （実行されません）
17. (not executed)
18. O-1 = {
(2001:0DB8::202:44ff:fe0a:f704; 2083; RADIUS/TLS; 10; 60),
（2001：0DB8 :: 202：44ff：fe0a：f704; 2083; RADIUS / TLS; 10; 60）、
(192.0.2.7; 2083; RADIUS/TLS; 20; 60)
}; O-2 = 0
19. No match with own listening address; terminate with tuple (O-1, O-2) from previous step.
19. 自分のリスニングアドレスと一致しません。前のステップのタプル（O-1、O-2）で終了します。
The implementation will then attempt to connect to two servers, with preference to [2001:0DB8::202:44ff:fe0a:f704]:2083 using the RADIUS/ TLS protocol.
次に、実装は、RADIUS / TLSプロトコルを使用して、[2001：0DB8 :: 202：44ff：fe0a：f704]：2083を優先して、2つのサーバーへの接続を試みます。
The discovery algorithm as defined in this document contains several options: the major ones are use of NAPTR vs. SRV; how to determine the authorization status of a contacted server for a given realm; and which trust anchors to consider trustworthy for the RADIUS conversation setup.
このドキュメントで定義されている検出アルゴリズムには、いくつかのオプションが含まれています。主なものは、NAPTRとSRVの使用です。指定されたレルムの接続先サーバーの承認ステータスを判別する方法。 RADIUS会話のセットアップで信頼できると見なすトラストアンカー。
Random parties that do not agree on the same set of options may not be able to interoperate. However, such a global interoperability is not intended by this document.
同じオプションセットに同意しないランダムパーティは、相互運用できない場合があります。ただし、このようなグローバルな相互運用性は、このドキュメントでは意図されていません。
Discovery as per this document becomes important inside a roaming consortium, which has set up roaming agreements with the other partners. Such roaming agreements require much more than a technical means of server discovery; there are administrative and contractual considerations at play (service contracts, back-office compensations, procedures, etc.).
このドキュメントによる発見は、他のパートナーとローミング契約を結んでいるローミングコンソーシアム内で重要になります。このようなローミング契約には、サーバー検出の技術的手段以上のものが必要です。現場での管理上および契約上の考慮事項（サービス契約、バックオフィスの補償、手順など）があります。
A roaming consortium's roaming agreement must include a profile of which choice points in this document to use. So as long as the roaming consortium can settle on one deployment profile, they will be able to interoperate based on that choice; this per-consortium interoperability is the intended scope of this document.
ローミングコンソーシアムのローミング契約には、このドキュメントで使用する選択ポイントのプロファイルを含める必要があります。したがって、ローミングコンソーシアムが1つの展開プロファイルで解決できる限り、それらはその選択に基づいて相互運用できます。このコンソーシアムごとの相互運用性は、このドキュメントの対象範囲です。
When using DNS without DNSSEC security extensions and validation for all of the replies to NAPTR, SRV, and A/AAAA requests as described in Section 3, the result of the discovery process can not be trusted. Even if it can be trusted (i.e., DNSSEC is in use), actual authorization of the discovered server to provide service for the given realm needs to be verified. A mechanism from Section 2.1.1.3 or equivalent MUST be used to verify authorization.
セクション3で説明されているように、DNSSECセキュリティ拡張およびNAPTR、SRV、およびA / AAAA要求に対するすべての応答の検証なしでDNSを使用する場合、検出プロセスの結果は信頼できません。信頼できる場合（DNSSECが使用されている場合など）でも、特定のレルムにサービスを提供するための検出されたサーバーの実際の承認を確認する必要があります。承認を確認するには、セクション2.1.1.3または同等のメカニズムを使用する必要があります。
The algorithm has a configurable completion timeout DNS_TIMEOUT defaulting to three seconds for RADIUS' operational reasons. The lookup of DNS resource records based on unverified user input is an attack vector for DoS attacks: an attacker might intentionally craft bogus DNS zones that take a very long time to reply (e.g., due to a particularly byzantine tree structure or artificial delays in responses).
このアルゴリズムには、RADIUSの運用上の理由から、デフォルトで3秒に設定可能な完了タイムアウトDNS_TIMEOUTがあります。未検証のユーザー入力に基づくDNSリソースレコードの検索は、DoS攻撃の攻撃ベクトルです。攻撃者は、応答に非常に長い時間がかかる偽のDNSゾーンを意図的に作成する可能性があります（たとえば、特にビザンチンなツリー構造または人為的な応答遅延のため） ）。
To mitigate this DoS vector, implementations SHOULD consider rate limiting either the amount of new executions of the discovery algorithm as a whole or the amount of intermediate responses to track, or at least the number of pending DNS queries. Implementations MAY choose lower values than the default for DNS_TIMEOUT to limit the impact of DoS attacks via that vector. They MAY also continue their attempt to resolve DNS records even after DNS_TIMEOUT has passed; a subsequent request for the same realm might benefit from retrieving the results anyway. The amount of time spent waiting for a result will influence the impact of a possible DoS attack; the waiting time value is implementation dependent and outside the scope of this specification.
このDoSベクトルを軽減するために、実装では、発見アルゴリズム全体の新しい実行の量または追跡する中間応答の量、または少なくとも保留中のDNSクエリの数のいずれかをレート制限することを検討する必要があります。実装は、DNS_TIMEOUTのデフォルトよりも低い値を選択して、そのベクトルを介したDoS攻撃の影響を制限する場合があります。また、DNS_TIMEOUTが経過した後でも、DNSレコードを解決する試みを続行する場合があります。同じレルムに対する後続のリクエストは、とにかく結果を取得することから利益を得るかもしれません。結果の待機に費やされた時間は、起こり得るDoS攻撃の影響に影響します。待機時間の値は実装に依存し、この仕様の範囲外です。
With dynamic discovery being enabled for a RADIUS server, and depending on the deployment scenario, the server may need to open up its target IP address and port for the entire Internet because arbitrary clients may discover it as a target for their authentication requests. If such clients are not part of the roaming consortium, the RADIUS/TLS connection setup phase will fail (which is intended), but the computational cost for the connection attempt is significant. When the port for a TLS-based service is open, the RADIUS server shares all the typical attack vectors for services based on TLS (such as HTTPS and SMTPS). Deployments of RADIUS/TLS with dynamic discovery should consider these attack vectors and take appropriate countermeasures (e.g., blacklisting known bad IPs on a firewall, rate limiting new connection attempts, etc.).
RADIUSサーバーで動的検出が有効になっている場合、展開シナリオによっては、サーバーがインターネット全体のターゲットIPアドレスとポートを開く必要がある場合があります。これは、任意のクライアントが認証要求のターゲットとして検出する可能性があるためです。そのようなクライアントがローミングコンソーシアムの一部ではない場合、RADIUS / TLS接続セットアップフェーズは失敗します（これは意図されています）が、接続試行の計算コストはかなり高くなります。 TLSベースのサービスのポートが開いている場合、RADIUSサーバーは、TLSに基づくサービス（HTTPSやSMTPSなど）の一般的な攻撃ベクトルをすべて共有します。動的検出を使用したRADIUS / TLSの展開では、これらの攻撃ベクトルを考慮し、適切な対策を講じる必要があります（たとえば、ファイアウォールで既知の不良IPをブラックリストに登録する、新しい接続試行をレート制限するなど）。
The classic RADIUS operational model (known, preconfigured peers, shared secret security, and mostly plaintext communication) and this new RADIUS dynamic discovery model (peer discovery with DNS, PKI security, and packet confidentiality) differ significantly in their impact on the privacy of end users trying to authenticate to a RADIUS server.
従来のRADIUS運用モデル（既知の事前構成されたピア、共有シークレットセキュリティ、およびほとんどがプレーンテキスト通信）とこの新しいRADIUS動的検出モデル（DNS、PKIセキュリティ、およびパケット機密性によるピア検出）は、エンドのプライバシーへの影響が大きく異なりますRADIUSサーバーへの認証を試みるユーザー。
With classic RADIUS, traffic in large environments gets aggregated by statically configured clearinghouses. The packets sent to those clearinghouses and their responses are mostly unprotected. As a consequence,
従来のRADIUSでは、大規模環境のトラフィックは、静的に構成されたクリアリングハウスによって集約されます。これらのクリアリングハウスに送信されるパケットとその応答は、ほとんど保護されていません。結果として、
o All intermediate IP hops can inspect most of the packet payload in clear text, including the User-Name and Calling-Station-Id attributes, and can observe which client sent the packet to which clearinghouse. This allows the creation of mobility profiles for any passive observer on the IP path.
o すべての中間IPホップは、User-Name属性とCalling-Station-Id属性を含むほとんどのパケットペイロードをクリアテキストで検査し、どのクライアントがどのクリアリングハウスにパケットを送信したかを監視できます。これにより、IPパス上の任意のパッシブオブザーバのモビリティプロファイルを作成できます。
o The existence of a central clearinghouse creates an opportunity for the clearinghouse to trivially create the same mobility profiles. The clearinghouse may or may not be trusted not to do this, e.g., by sufficiently threatening contractual obligations.
o 中央のクリアリングハウスの存在は、クリアリングハウスが同じモビリティプロファイルを簡単に作成する機会を生み出します。クリアリングハウスは、たとえば契約上の義務を十分に脅かすなどして、これを行わないことを信頼する場合としない場合があります。
o In addition to that, with the clearinghouse being a RADIUS intermediate in possession of a valid shared secret, the clearinghouse can observe and record even the security-critical RADIUS attributes such as User-Password. This risk may be mitigated by choosing authentication payloads that are cryptographically secured and do not use the attribute User-Password -- such as certain EAP types.
o それに加えて、クリアリングハウスは有効な共有シークレットを保持するRADIUS中間体であるので、クリアリングハウスは、ユーザーパスワードなどのセキュリティ上重要なRADIUS属性でさえ監視および記録できます。このリスクは、暗号で保護され、特定のEAPタイプなどの属性User-Passwordを使用しない認証ペイロードを選択することで軽減できます。
o There is no additional information disclosure to parties outside the IP path between the RADIUS client and server (in particular, no DNS servers learn about realms of current ongoing authentications).
o RADIUSクライアントとサーバー間のIPパスの外部の関係者に対する追加の情報開示はありません（特に、DNSサーバーは現在進行中の認証の領域について学習しません）。
With RADIUS and dynamic discovery,
RADIUSと動的検出により、
o This protocol allows for RADIUS clients to identify and directly connect to the RADIUS home server. This can eliminate the use of clearinghouses to do forwarding of requests, and it also eliminates the ability of the clearinghouse to then aggregate the user information that flows through it. However, there are reasons why clearinghouses might still be used. One reason to keep a clearinghouse is to act as a gateway for multiple backends in a company; another reason may be a requirement to sanitize RADIUS datagrams (filter attributes, tag requests with new attributes, etc.).
oこのプロトコルにより、RADIUSクライアントはRADIUSホームサーバーを識別して直接接続できます。これにより、クリアリングハウスを使用してリクエストを転送する必要がなくなり、クリアリングハウスがフローするユーザー情報を集約する機能もなくなります。ただし、クリアリングハウスが引き続き使用される理由はいくつかあります。クリアリングハウスを維持する1つの理由は、企業内の複数のバックエンドのゲートウェイとして機能することです。別の理由として、RADIUSデータグラムをサニタイズする必要がある場合があります（属性のフィルター、新しい属性による要求のタグ付けなど）。
o Even where intermediate proxies continue to be used for reasons unrelated to dynamic discovery, the number of such intermediates may be reduced by removing those proxies that are only deployed for pure request routing reasons. This reduces the number of entities that can inspect the RADIUS traffic.
o 動的検出とは無関係の理由で中間プロキシが引き続き使用される場合でも、純粋な要求ルーティングの理由でのみ展開されているプロキシを削除することにより、そのような中間の数を減らすことができます。これにより、RADIUSトラフィックを検査できるエンティティの数が減少します。
o RADIUS clients that make use of dynamic discovery will need to query the Domain Name System and use a user's realm name as the query label. A passive observer on the IP path between the RADIUS client and the DNS server(s) being queried can learn that a user of that specific realm was trying to authenticate at that RADIUS client at a certain point in time. This may or may not be sufficient for the passive observer to create a mobility profile. During the recursive DNS resolution, a fair number of DNS servers and the IP hops in between those get to learn that information. Not every single authentication triggers DNS lookups, so there is no one-to-one relation of leaked realm information and the number of authentications for that realm.
o 動的検出を利用するRADIUSクライアントは、ドメインネームシステムにクエリを実行し、クエリラベルとしてユーザーのレルム名を使用する必要があります。 RADIUSクライアントとクエリ対象のDNSサーバー間のIPパス上のパッシブオブザーバーは、特定のレルムのユーザーが特定の時点でそのRADIUSクライアントで認証を試みていたことを知ることができます。これは、受動的観察者が移動度プロファイルを作成するには十分な場合とそうでない場合があります。再帰的なDNS解決中に、かなりの数のDNSサーバーとそれらの間のIPホップがその情報を取得します。すべての単一の認証がDNSルックアップをトリガーするわけではないため、リークされたレルム情報とそのレルムの認証数の1対1の関係はありません。
o Since dynamic discovery operates on a RADIUS hop-by-hop basis, there is no guarantee that the RADIUS payload is not transmitted between RADIUS systems that do not make use of this algorithm, and they possibly use other transports such as RADIUS/UDP. On such hops, the enhanced privacy is jeopardized.
o 動的検出はRADIUSホップバイホップベースで動作するため、このアルゴリズムを使用しないRADIUSシステム間でRADIUSペイロードが送信されず、RADIUS / UDPなどの他のトランスポートを使用する可能性もあります。そのようなホップでは、強化されたプライバシーは危険にさらされます。
In summary, with classic RADIUS, few intermediate entities learn very detailed data about every ongoing authentication, while with dynamic discovery, many entities learn only very little about recently authenticated realms.
要約すると、従来のRADIUSでは、進行中のすべての認証に関する非常に詳細なデータを学習する中間エンティティはほとんどありませんが、動的検出では、最近認証されたレルムについてはほとんど学習しません。
Per this document, IANA has added the following entries in existing registries:
このドキュメントに従って、IANAは既存のレジストリに次のエントリを追加しました。
o S-NAPTR Application Service Tags registry
o S-NAPTRアプリケーションサービスタグレジストリ
* aaa+auth
* aaa + auth
* aaa+acct
* 私+行為
* aaa+dynauth
* 私+デネス
o S-NAPTR Application Protocol Tags registry
o S-NAPTRアプリケーションプロトコルタグレジストリ
* radius.tls.tcp
* radius.tls.tcp
* radius.dtls.udp
* radius.dtls.udp
This document reserves the use of the "radiustls" and "radiusdtls" service names. Registration information as per Section 8.1.1 of [RFC6335] is as follows:
このドキュメントでは、「radiustls」および「radiusdtls」サービス名の使用を予約しています。 [RFC6335]のセクション8.1.1による登録情報は次のとおりです。
Service Name: radiustls; radiusdtls
サービス名：radiustls; radiusdtls
Transport Protocols: TCP (for radiustls), UDP (for radiusdtls)
トランスポートプロトコル：TCP（radiustlsの場合）、UDP（radiustlsの場合）
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: Authentication, Accounting, and Dynamic Authorization via the RADIUS protocol. These service names are used to construct the SRV service labels "_radiustls" and "_radiusdtls" for discovery of RADIUS/TLS and RADIUS/DTLS servers, respectively.
説明：RADIUSプロトコルを介した認証、アカウンティング、および動的承認。これらのサービス名は、それぞれRADIUS / TLSおよびRADIUS / DTLSサーバーの検出用のSRVサービスラベル「_radiustls」および「_radiusdtls」を構築するために使用されます。
Reference: RFC 7585
リファレンス：RFC 7585
This specification makes use of the SRV protocol identifiers "_tcp" and "_udp", which are mentioned as early as [RFC2782] but do not appear to be assigned in an actual registry. Since they are in widespread use in other protocols, this specification refrains from requesting a new registry "RADIUS/TLS SRV Protocol Registry" and continues to make use of these tags implicitly.
この仕様は、SRVプロトコル識別子「_tcp」と「_udp」を使用します。これらは、[RFC2782]として早くから言及されていますが、実際のレジストリには割り当てられていないようです。他のプロトコルで広く使用されているため、この仕様では、新しいレジストリ「RADIUS / TLS SRVプロトコルレジストリ」を要求せず、これらのタグを暗黙的に使用し続けます。
Per this document, a number of Object Identifiers have been assigned. They are now under the control of IANA following [RFC7299].
このドキュメントによれば、いくつかのオブジェクト識別子が割り当てられています。彼らは現在[RFC7299]に従ってIANAの管理下にあります。
IANA has assigned the following identifiers:
IANAは次の識別子を割り当てました。
85 has been assigned from the "SMI Security for PKIX Module Identifier" registry. The description is id-mod-nai-realm-08.
85は、「SMI Security for PKIX Module Identifier」レジストリから割り当てられています。説明はid-mod-nai-realm-08です。
8 has been assigned from the "SMI Security for PKIX Other Name Forms" registry. The description is id-on-naiRealm.
8は、「SMI Security for PKIX Other Name Forms」レジストリから割り当てられています。説明はid-on-naiRealmです。
[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>。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <http://www.rfc-editor.org/info/rfc2782>.
[RFC2782] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、DOI 10.17487 / RFC2782、2000年2月、<http：// www.rfc-editor.org/info/rfc2782>。
[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>。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, DOI 10.17487/RFC2866, June 2000, <http://www.rfc-editor.org/info/rfc2866>.
[RFC2866]リグニー、C。、「RADIUSアカウンティング」、RFC 2866、DOI 10.17487 / RFC2866、2000年6月、<http://www.rfc-editor.org/info/rfc2866>。
[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>。
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, DOI 10.17487/RFC5176, January 2008, <http://www.rfc-editor.org/info/rfc5176>.
[RFC5176] Chiba、M.、Dommety、G.、Eklund、M.、Mitton、D.、and B. Aboba、 "Dynamic Authorization Extensions to Remote Authentication Dial In User Service（RADIUS）"、RFC 5176、DOI 10.17487 / RFC5176、2008年1月、<http://www.rfc-editor.org/info/rfc5176>。
[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>。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, <http://www.rfc-editor.org/info/rfc5891>.
[RFC5891] Klensin、J。、「Internationalized Domain Names in Applications（IDNA）：Protocol」、RFC 5891、DOI 10.17487 / RFC5891、2010年8月、<http://www.rfc-editor.org/info/rfc5891>。
[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>。
[RFC7360] DeKok, A., "Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS", RFC 7360, DOI 10.17487/RFC7360, September 2014, <http://www.rfc-editor.org/info/rfc7360>.
[RFC7360] DeKok、A。、「RADIUSのトランスポート層としてのデータグラムトランスポート層セキュリティ（DTLS）」、RFC 7360、DOI 10.17487 / RFC7360、2014年9月、<http://www.rfc-editor.org/info/ rfc7360>。
[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>。
[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>。
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <http://www.rfc-editor.org/info/rfc6335>.
[RFC6335]綿、M。、エガート、L。、タッチ、J。、ウェスターランド、M。、およびS.チェシャー、「サービス名とトランスポートプロトコルのポート番号レジストリの管理のためのInternet Assigned Numbers Authority（IANA）手順"、BCP 165、RFC 6335、DOI 10.17487 / RFC6335、2011年8月、<http://www.rfc-editor.org/info/rfc6335>。
[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>。
[RFC7299] Housley, R., "Object Identifier Registry for the PKIX Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014, <http://www.rfc-editor.org/info/rfc7299>.
[RFC7299] Housley、R。、「PKIXワーキンググループのオブジェクトIDレジストリ」、RFC 7299、DOI 10.17487 / RFC7299、2014年7月、<http://www.rfc-editor.org/info/rfc7299>。
[RFC7593] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam Architecture for Network Roaming", RFC 7593, DOI 10.17487/RFC7593, September 2015, <http://www.rfc-editor.org/info/rfc7593>.
[RFC7593] Wierenga、K.、Winter、S。、およびT. Wolniewicz、「ネットワークローミング用のeduroamアーキテクチャ」、RFC 7593、DOI 10.17487 / RFC7593、2015年9月、<http://www.rfc-editor.org / info / rfc7593>。
PKIXNaiRealm08 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-nai-realm-08(85) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
ベギン
-- EXPORTS ALL --
-すべてエクスポート-
IMPORTS
輸入
id-pkix
FROM PKIX1Explicit-2009
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-explicit-02(51)}
-- from RFCs 5280 and 5912
OTHER-NAME
FROM PKIX1Implicit-2009
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)}
-- from RFCs 5280 and 5912
;
-- Service Name Object Identifier
-サービス名オブジェクト識別子
id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
id-on-naiRealm OBJECT IDENTIFIER ::= { id-on 8 }
-- Service Name
- サービス名
naiRealm OTHER-NAME ::= { NAIRealm IDENTIFIED BY { id-on-naiRealm }}
ub-naiRealm-length INTEGER ::= 255
NAIRealm ::= UTF8String (SIZE (1..ub-naiRealm-length))
END
終わり
Authors' Addresses
著者のアドレス
Stefan Winter Fondation RESTENA 6, rue Richard Coudenhove-Kalergi Luxembourg 1359 Luxembourg
Stefan Winter Fondation RESTENA 6、rue Richard Coudenhove-Kalergi Luxembourg 1359ルクセンブルグ
Phone: +352 424409 1
Fax: +352 422473
Email: stefan.winter@restena.lu
URI: http://www.restena.lu
Mike McCauley AirSpayce Pty Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia
Mike McCauley AirSpayce Pty Ltd 9 Bulbul Place Currumbin Waters QLD 4223オーストラリア
Phone: +61 7 5598 7474
Email: mikem@airspayce.com
URI: http://www.airspayce.com