[要約] RFC 7542は、ネットワークアクセス識別子（NAI）に関する標準化された仕様であり、ネットワーク接続の識別と認証に使用されます。このRFCの目的は、NAIの構造と使用方法を定義し、ネットワークアクセスの管理とセキュリティを向上させることです。
Internet Engineering Task Force (IETF) A. DeKok
Request for Comments: 7542 FreeRADIUS
Obsoletes: 4282 May 2015
Category: Standards Track
ISSN: 2070-1721
The Network Access Identifier
ネットワークアクセス識別子
Abstract
概要
In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each other's users. This document defines the syntax for the Network Access Identifier (NAI), the user identifier submitted by the client prior to accessing resources. This document is a revised version of RFC 4282. It addresses issues with international character sets and makes a number of other corrections to RFC 4282.
ドメイン間認証サービスを提供するには、ドメインが互いのユーザーを識別するために使用できる標準化された方法が必要です。このドキュメントでは、リソースにアクセスする前にクライアントから送信されたユーザー識別子であるネットワークアクセス識別子（NAI）の構文を定義します。このドキュメントは、RFC 4282の改訂版です。国際的な文字セットの問題に対処し、RFC 4282に他の多くの修正を加えます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc7542.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7542で入手できます。
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に記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部の著作権を管理する人は、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Terminology ................................................6
1.2. Requirements Language ......................................7
1.3. Purpose ....................................................7
1.4. Motivation .................................................9
2. NAI Definition .................................................10
2.1. UTF-8 Syntax and Normalization ............................10
2.2. Formal Syntax .............................................11
2.3. NAI Length Considerations .................................11
2.4. Support for Username Privacy ..............................12
2.5. International Character Sets ..............................13
2.6. The Normalization Process .................................14
2.6.1. Issues with the Normalization Process ..............15
2.7. Use in Other Protocols ....................................16
2.8. Using the NAI Format for Other Identifiers ................17
3. Routing inside of AAA Systems ..................................18
3.1. Compatibility with Email Usernames ........................19
3.2. Compatibility with DNS ....................................20
3.3. Realm Construction ........................................20
3.3.1. Historical Practices ...............................21
3.4. Examples ..................................................22
4. Security Considerations ........................................23
4.1. Correlation of Identities over Time and Protocols .........23
4.2. Multiple Identifiers ......................................24
5. Administration of Names ........................................25
6. References .....................................................26
6.1. Normative References ......................................26
6.2. Informative References ....................................26
Appendix A. Changes from RFC 4282 .................................29
Acknowledgments ...................................................30
Author's Address ..................................................30
Considerable interest exists for a set of features that fit within the general category of inter-domain authentication, or "roaming capability" for network access, including dialup Internet users, Virtual Private Network (VPN) usage, wireless LAN authentication, and other applications.
ドメイン間認証の一般的なカテゴリ、またはダイヤルアップインターネットユーザー、仮想プライベートネットワーク（VPN）の使用、無線LAN認証、その他のアプリケーションを含むネットワークアクセスの「ローミング機能」に該当する一連の機能には、かなりの関心が存在します。
By "inter-domain authentication", this document refers to situations where a user has authentication credentials at one "home" domain but is able to present them at a second "visited" domain to access certain services at the visited domain. The two domains generally have a pre-existing relationship, so that the credentials can be passed from the visited domain to the home domain for verification. The home domain typically responds with a permit/deny response, which may also include authorization parameters that the visited domain is expected to enforce on the user.
「ドメイン間認証」とは、このドキュメントでは、ユーザーが1つの「ホーム」ドメインで認証資格情報を持っているが、2番目の「訪問済み」ドメインでそれらを提示して、訪問済みドメインの特定のサービスにアクセスできる状況を指します。通常、2つのドメインには既存の関係があるため、確認のために訪問先ドメインからホームドメインに資格情報を渡すことができます。ホームドメインは通常、許可/拒否応答で応答します。これには、訪問済みドメインがユーザーに適用すると予想される認証パラメーターも含まれる場合があります。
That is, the "roaming" scenario involves a user visiting, or "roaming" to, a non-home domain and requesting the use of services at that visited domain.
つまり、「ローミング」シナリオには、ユーザーが非ホームドメインを訪問または「ローミング」し、その訪問したドメインでサービスの使用を要求することが含まれます。
Interested parties have included the following:
利害関係者には以下が含まれます。
* Regional Internet Service Providers (ISPs) operating within a particular state or province, looking to combine their efforts with those of other regional providers to offer dialup service over a wider area.
* 特定の州または地方で事業を展開している地域インターネットサービスプロバイダー（ISP）。他の地域プロバイダーの取り組みと組み合わせて、より広いエリアにダイヤルアップサービスを提供することを目指しています。
* Telecommunications companies who wish to combine their operations with those of one or more companies in other areas or nations, in order to offer more comprehensive network access service in areas where there is no native service (e.g., in another country).
* ネイティブサービスがない地域（他の国など）でより包括的なネットワークアクセスサービスを提供するために、他の地域または国の1つ以上の会社の事業と統合したい電気通信会社。
* Wireless LAN hotspots providing service to one or more ISPs.
* 1つ以上のISPにサービスを提供する無線LANホットスポット。
* Businesses desiring to offer their employees a comprehensive package of dialup services on a global basis. Those services may include Internet access as well as secure access to corporate intranets via a VPN, enabled by tunneling protocols such as the Point-to-Point Tunneling Protocol (PPTP) [RFC2637], the Layer 2 Forwarding (L2F) protocol [RFC2341], the Layer 2 Tunneling Protocol (L2TP) [RFC2661], and the IPsec tunnel mode [RFC4301].
* 従業員にグローバルなダイヤルアップサービスの包括的なパッケージを提供することを望む企業。これらのサービスには、インターネットアクセスだけでなく、VPNを介した企業イントラネットへの安全なアクセスも含まれ、ポイントツーポイントトンネリングプロトコル（PPTP）[RFC2637]、レイヤー2転送（L2F）プロトコル[RFC2341]などのトンネリングプロトコルによって有効になります。 、レイヤ2トンネリングプロトコル（L2TP）[RFC2661]、およびIPsecトンネルモード[RFC4301]。
* Other protocols that are interested in leveraging the users' credentials in order to take advantage of an existing authentication framework.
* 既存の認証フレームワークを利用するためにユーザーの資格情報を活用することに関心がある他のプロトコル。
In order to enhance the interoperability of these services, it is necessary to have a standardized method for identifying users. This document defines syntax for the Network Access Identifier (NAI). Examples of implementations that use the NAI, and descriptions of its semantics, can be found in [RFC2194].
これらのサービスの相互運用性を強化するには、ユーザーを識別するための標準化された方法が必要です。このドキュメントでは、ネットワークアクセス識別子（NAI）の構文を定義します。 NAIを使用する実装の例とそのセマンティクスの説明は、[RFC2194]にあります。
When the NAI was defined for network access, it had the side effect of defining an identifier that could be used in non-AAA systems. Some non-AAA systems defined identifiers that were compatible with the NAI, and deployments used the NAI. This process simplified the management of credentials, by reusing the same credential in multiple situations. Protocols that reuse the same credential or the same identifier format can benefit from this simplified management. The alternative is to have protocol-specific credentials or identifier formats, which increases cost to both the user and the administrator.
NAIがネットワークアクセス用に定義されたとき、非AAAシステムで使用できる識別子を定義するという副作用がありました。一部の非AAAシステムは、NAIと互換性のある識別子を定義し、展開ではNAIを使用しました。このプロセスは、複数の状況で同じ資格情報を再利用することにより、資格情報の管理を簡素化しました。同じ資格情報または同じ識別子形式を再利用するプロトコルは、この簡素化された管理から恩恵を受けることができます。別の方法は、プロトコル固有の資格情報または識別子の形式を使用することです。これにより、ユーザーと管理者の両方のコストが増加します。
There are privacy implications to using one identifier across multiple protocols. See Sections 2.7 and 4 for further discussion of this topic.
複数のプロトコルで1つの識別子を使用することにはプライバシーの影響があります。このトピックの詳細については、セクション2.7および4を参照してください。
The goal of this document is to define the format of an identifier that can be used in many protocols. A protocol may transport an encoded version of the NAI (e.g., '.' as %2E). However, the definition of the NAI is protocol independent. The goal of this document is to encourage the widespread adoption of the NAI format. This adoption will decrease the work required to leverage identification and authentication in other protocols. It will also decrease the complexity of non-AAA systems for end users and administrators.
このドキュメントの目的は、多くのプロトコルで使用できる識別子の形式を定義することです。プロトコルは、NAIのエンコードされたバージョンを転送する場合があります（たとえば、「。」は％2Eとして）。ただし、NAIの定義はプロトコルに依存しません。このドキュメントの目的は、NAIフォーマットの広範な採用を促進することです。この採用により、他のプロトコルで識別と認証を活用するために必要な作業が減少します。また、エンドユーザーおよび管理者にとって、非AAAシステムの複雑さを軽減します。
This document only suggests that the NAI format be used; it does not require such use. Many protocols already define their own identifier formats. Some of these are incompatible with the NAI, while others allow the NAI in addition to non-NAI identifiers. The definition of the NAI in this document has no requirements on protocol specifications, implementations, or deployments.
このドキュメントでは、NAI形式を使用することのみを提案しています。そのような使用は必要ありません。多くのプロトコルはすでに独自の識別子フォーマットを定義しています。これらの一部はNAIと互換性がありませんが、非NAI識別子に加えてNAIを許可するものもあります。このドキュメントでのNAIの定義には、プロトコルの仕様、実装、または配置に関する要件はありません。
However, this document suggests that using one standard identifier format is preferable to using multiple incompatible identifier formats. Where identifiers need to be used in new protocols and/or specifications, it is RECOMMENDED that the format of the NAI be used. That is, the interpretation of the identifier is context specific, while the format of the identifier remains the same. These issues are discussed in more detail in Section 2.8, below.
ただし、このドキュメントでは、1つの標準識別子形式を使用する方が、互換性のない複数の識別子形式を使用するよりも望ましいことを示唆しています。新しいプロトコルや仕様で識別子を使用する必要がある場合は、NAIの形式を使用することをお勧めします。つまり、識別子の解釈はコンテキスト固有ですが、識別子の形式は同じです。これらの問題については、以下のセクション2.8で詳しく説明します。
The recommendation for a standard identifier format is not a recommendation that each user have one universal identifier. In contrast, this document allows for the use of multiple identifiers and recommends the use of anonymous identifiers where those identifiers are publicly visible.
標準識別子形式の推奨事項は、各ユーザーが1つのユニバーサル識別子を持つことを推奨するものではありません。対照的に、このドキュメントでは複数の識別子の使用が可能であり、それらの識別子が公開されている匿名識別子の使用を推奨しています。
This document is a revised version of [RFC4282], which originally defined internationalized NAIs. Differences and enhancements compared to that document are listed in Appendix A.
このドキュメントは、国際化されたNAIを最初に定義した[RFC4282]の改訂版です。そのドキュメントとの違いと機能強化は、付録Aにリストされています。
This document frequently uses the following terms:
このドキュメントでは、次の用語を頻繁に使用しています。
"Local" or "Localized" Text
「ローカル」または「ローカライズ」テキスト
"Local" or "localized" text is text that is in either non-UTF-8 or non-normalized form. The character set, encoding, and locale are (in general) unknown to Authentication, Authorization, and Accounting (AAA) network protocols. The client that "knows" the locale may have a different concept of this text than other AAA entities, which do not know the same locale.
「ローカル」または「ローカライズされた」テキストとは、UTF-8以外の形式または正規化されていない形式のテキストです。文字セット、エンコーディング、およびロケールは、（一般に）認証、承認、およびアカウンティング（AAA）ネットワークプロトコルには不明です。ロケールを「知っている」クライアントは、このテキストの概念が、同じロケールを知らない他のAAAエンティティとは異なる場合があります。
Network Access Identifier
ネットワークアクセス識別子
The Network Access Identifier (NAI) is a common format for user identifiers submitted by a client during authentication. The purpose of the NAI is to allow a user to be associated with an account name, as well as to assist in the routing of the authentication request across multiple domains. Please note that the NAI may not necessarily be the same as the user's email address or the user identifier submitted in an application-layer authentication.
ネットワークアクセス識別子（NAI）は、認証中にクライアントから送信されるユーザー識別子の一般的な形式です。 NAIの目的は、ユーザーをアカウント名に関連付けられるようにすることと、複数のドメインにわたる認証要求のルーティングを支援することです。 NAIは、必ずしもユーザーのメールアドレスまたはアプリケーション層認証で送信されたユーザーIDと同じであるとは限らないことに注意してください。
Network Access Server
ネットワークアクセスサーバー
The Network Access Server (NAS) is the device that clients connect to in order to get access to the network. In PPTP terminology, this is referred to as the PPTP Access Concentrator (PAC), and in L2TP terminology, it is referred to as the L2TP Access Concentrator (LAC). In IEEE 802.11, it is referred to as an Access Point.
ネットワークアクセスサーバー（NAS）は、ネットワークにアクセスするためにクライアントが接続するデバイスです。これは、PPTP用語ではPPTPアクセスコンセントレータ（PAC）と呼ばれ、L2TP用語ではL2TPアクセスコンセントレータ（LAC）と呼ばれます。 IEEE 802.11では、アクセスポイントと呼ばれます。
Roaming Capability
ローミング機能
Roaming capability can be loosely defined as the ability to use any one of multiple Internet Service Providers (ISPs), while maintaining a formal customer-vendor relationship with only one. Examples of cases where roaming capability might be required include ISP "confederations" and ISP-provided corporate network access support.
ローミング機能は、正式な顧客とベンダーの関係を1つだけ維持しながら、複数のインターネットサービスプロバイダー（ISP）のいずれかを使用する機能として大まかに定義できます。ローミング機能が必要になる場合の例としては、ISP「コンフェデレーション」やISP提供の企業ネットワークアクセスサポートなどがあります。
Normalization or Canonicalization
正規化または正規化
These terms are defined in Section 4 of [RFC6365]; those definitions are incorporated here by reference.
これらの用語は、[RFC6365]のセクション4で定義されています。これらの定義は、参照によりここに組み込まれます。
Locale
地元
This term is defined in [RFC6365], Section 8; that definition is incorporated here by reference.
この用語は、[RFC6365]のセクション8で定義されています。その定義は参照により本明細書に組み込まれる。
Tunneling Service
トンネリングサービス
A tunneling service is any network service enabled by tunneling protocols such as PPTP, L2F, L2TP, and IPsec tunnel mode. One example of a tunneling service is secure access to corporate intranets via a Virtual Private Network (VPN).
トンネリングサービスは、PPTP、L2F、L2TP、IPsecトンネルモードなどのトンネリングプロトコルによって有効化されるネットワークサービスです。トンネリングサービスの一例は、仮想プライベートネットワーク（VPN）を介した企業イントラネットへの安全なアクセスです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
As described in [RFC2194], there are a number of providers offering network access services, and essentially all Internet Service Providers are involved in roaming consortia.
[RFC2194]で説明されているように、ネットワークアクセスサービスを提供するプロバイダーは多数あり、基本的にすべてのインターネットサービスプロバイダーがローミングコンソーシアムに関与しています。
In order to be able to offer roaming capability, one of the requirements is to be able to identify the user's home authentication server. For use in roaming, this function is accomplished via the Network Access Identifier (NAI) submitted by the user to the NAS in the initial network authentication. It is also expected that NASes will use the NAI as part of the process of opening a new tunnel, in order to determine the tunnel endpoint.
ローミング機能を提供できるようにするための要件の1つは、ユーザーのホーム認証サーバーを識別できることです。ローミングで使用する場合、この機能は、初期ネットワーク認証でユーザーがNASに送信したネットワークアクセス識別子（NAI）を介して実行されます。 NASは、トンネルエンドポイントを決定するために、新しいトンネルを開くプロセスの一部としてNAIを使用することも予想されます。
This document suggests that other protocols can take advantage of the NAI format. Many protocols include authentication capabilities, including defining their own identifier formats. These identifiers can then end up being transported in AAA protocols, so that the originating protocols can leverage AAA for user authentication. There is therefore a need for a definition of a user identifier that can be used in multiple protocols.
このドキュメントは、他のプロトコルがNAI形式を利用できることを示唆しています。多くのプロトコルには、独自の識別子形式の定義を含む認証機能が含まれています。これらの識別子は最終的にAAAプロトコルで転送されるため、元のプロトコルはAAAを利用してユーザー認証を行うことができます。したがって、複数のプロトコルで使用できるユーザー識別子の定義が必要です。
While the NAI is defined herein, it should be noted that existing protocols and deployments do not always use it. AAA systems MUST therefore be able to handle user identifiers that are not in the NAI format. The process by which that is done is outside of the scope of this document.
ここではNAIが定義されていますが、既存のプロトコルと展開では常にそれが使用されるわけではないことに注意してください。したがって、AAAシステムは、NAI形式ではないユーザー識別子を処理できる必要があります。それが行われるプロセスは、このドキュメントの範囲外です。
Non-AAA systems can accept user identifiers in forms other than the NAI. This specification does not forbid that practice. It only codifies the format and interpretation of the NAI. This document cannot change existing protocols or practices. It can, however, suggest that using a consistent form for a user identifier is of benefit to the community.
非AAAシステムは、NAI以外の形式のユーザー識別子を受け入れることができます。この仕様では、そのような行為を禁じていません。 NAIの形式と解釈を成文化するだけです。このドキュメントは、既存のプロトコルまたはプラクティスを変更することはできません。ただし、ユーザーIDに一貫したフォームを使用することは、コミュニティにとって有益であることを示唆しています。
This document does not make any protocol-specific definitions for an identifier format, and it does not make changes to any existing protocol. Instead, it defines a protocol-independent form for the NAI. It is hoped that the NAI is a user identifier that can be used in multiple protocols.
このドキュメントでは、識別子形式のプロトコル固有の定義は行わず、既存のプロトコルを変更しません。代わりに、NAIのプロトコルに依存しない形式を定義します。 NAIが複数のプロトコルで使用できるユーザー識別子であることが望まれます。
Using a common identifier format simplifies protocols requiring authentication, as they no longer need to specify a protocol-specific format for user identifiers. It increases security, as multiple identifier formats allow attackers to make contradictory claims without being detected (see Section 4.2 for further discussion of this topic). It simplifies deployments, as a user can have one identifier in multiple contexts, which allows them to be uniquely identified, so long as that identifier is itself protected against unauthorized access.
共通の識別子形式を使用すると、ユーザー識別子にプロトコル固有の形式を指定する必要がなくなるため、認証が必要なプロトコルが簡素化されます。複数の識別子形式により、攻撃者が検出されずに矛盾する主張を行うことができるため、セキュリティが向上します（このトピックの詳細については、セクション4.2を参照してください）。ユーザーは複数のコンテキストで1つの識別子を持つことができ、識別子自体が不正アクセスから保護されている限り、一意に識別できるため、展開が簡素化されます。
In short, having a standard is better than having no standard at all.
簡単に言うと、標準があることは、標準がないことよりも優れています。
The changes from [RFC4282] are listed in detail in Appendix A. However, some additional discussion is appropriate to motivate those changes.
[RFC4282]からの変更点は、付録Aに詳細に記載されています。ただし、これらの変更の動機付けには、いくつかの追加の議論が適切です。
The motivation to revise [RFC4282] began with internationalization concerns raised in the context of [EDUROAM]. Section 2.1 of [RFC4282] defines ABNF for realms and limits the realm grammar to English letters, digits, and the hyphen "-" character. The intent appears to have been to encode, compare, and transport realms with the Punycode [RFC3492] encoding form as described in [RFC5891]. There are a number of problems with this approach:
[RFC4282]を改訂する動機は、[EDUROAM]のコンテキストで提起された国際化の懸念から始まりました。 [RFC4282]のセクション2.1は、レルムのABNFを定義し、レルムの文法を英字、数字、ハイフン「-」文字に制限しています。その意図は、[RFC5891]で説明されているPunycode [RFC3492]エンコード形式でレルムをエンコード、比較、および転送することであったと思われます。このアプローチにはいくつかの問題があります。
* The [RFC4282] ABNF is not aligned with internationalization of DNS.
* [RFC4282] ABNFはDNSの国際化に対応していません。
* The requirement in Section 2.1 of [RFC4282] that realms are ASCII conflicts with the Extensible Authentication Protocol (EAP) as defined in [RFC3748], and RADIUS, which are both 8-bit clean, and which both recommend the use of UTF-8 for identifiers.
* レルムがASCIIであるという[RFC4282]のセクション2.1の要件は、[RFC3748]で定義されている拡張認証プロトコル（EAP）およびRADIUSと競合します。これらはどちらも8ビットクリーンであり、どちらもUTF-8の使用を推奨しています識別子。
* Section 2.4 of [RFC4282] required mappings that are language specific and that are nearly impossible for intermediate nodes to perform correctly without information about that language.
* [RFC4282]のセクション2.4では、言語固有のマッピングが必要であり、中間ノードがその言語に関する情報なしに正しく実行することはほぼ不可能です。
* Section 2.4 of [RFC4282] requires normalization of usernames, which may conflict with local system or administrative requirements.
* [RFC4282]のセクション2.4では、ユーザー名の正規化が必要です。これは、ローカルシステムまたは管理要件と競合する可能性があります。
* The recommendations in Section 2.4 of [RFC4282] for treatment of bidirectional characters have proven to be unworkable.
* [RFC4282]のセクション2.4にある双方向キャラクターの扱いに関する推奨事項は、機能しないことが証明されています。
* The prohibition of the use of unassigned code points in Section 2.4 of [RFC4282] effectively prohibits support for new scripts.
* [RFC4282]のセクション2.4で割り当てられていないコードポイントの使用を禁止すると、新しいスクリプトのサポートが事実上禁止されます。
* No Authentication, Authorization, and Accounting (AAA) client, proxy, or server has implemented any of the requirements in Section 2.4 of [RFC4282], among other sections.
* 認証、承認、アカウンティング（AAA）クライアント、プロキシ、またはサーバーは、[RFC4282]のセクション2.4の要件を実装していません。
With international roaming growing in popularity, it is important for these issues to be corrected in order to provide robust and interoperable network services.
国際ローミングの人気が高まる中、堅牢で相互運用可能なネットワークサービスを提供するために、これらの問題を修正することが重要です。
Furthermore, this document was motivated by a desire to codify existing practice related to the use of the NAI format and to encourage widespread use of the format.
さらに、このドキュメントは、NAIフォーマットの使用に関連する既存の慣行を体系化し、フォーマットの広範な使用を奨励したいという欲求に動機付けられました。
UTF-8 characters can be defined in terms of octets using the following ABNF [RFC5234], taken from [RFC3629]:
UTF-8文字は、[RFC3629]から取られた次のABNF [RFC5234]を使用してオクテットに関して定義できます。
UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4
UTF8-2 = %xC2-DF UTF8-tail
UTF8-3 = %xE0 %xA0-BF UTF8-tail /
%xE1-EC 2( UTF8-tail ) /
%xED %x80-9F UTF8-tail /
%xEE-EF 2( UTF8-tail )
UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) /
%xF1-F3 3( UTF8-tail ) /
%xF4 %x80-8F 2( UTF8-tail )
UTF8-tail = %x80-BF
These are normatively defined in [RFC3629] but are repeated in this document for reasons of convenience.
これらは[RFC3629]で規範的に定義されていますが、便宜上、このドキュメントでは繰り返されています。
See [RFC5198] and Section 2.6 of this specification for a discussion of normalization. Strings that are not Normal Form Composed (NFC) are not valid NAIs and SHOULD NOT be treated as such. Implementations that expect to receive an NAI but that instead receive non-normalized (but otherwise valid) UTF-8 strings instead SHOULD attempt to create a local version of the NAI, which is normalized from the input identifier. This local version can then be used for local processing. This local version of the identifier MUST NOT be used outside of the local context.
正規化の説明については、[RFC5198]とこの仕様のセクション2.6を参照してください。 Normal Form Composed（NFC）ではない文字列は有効なNAIではなく、そのように扱われるべきではありません（SHOULD NOT）。 NAIを受け取ることを期待しているが、正規化されていない（ただし有効な）UTF-8文字列を受け取る実装は、入力識別子から正規化されたNAIのローカルバージョンの作成を試みる必要があります（SHOULD）。このローカルバージョンは、ローカル処理に使用できます。このローカルバージョンの識別子は、ローカルコンテキストの外で使用してはなりません（MUST NOT）。
Where protocols carry identifiers that are expected to be transported over a AAA protocol, it is RECOMMENDED that the identifiers be in NAI format. Where the identifiers are not in the NAI format, it is up to the AAA systems to discover this and to process them. This document does not suggest how that is done. However, existing practice indicates that it is possible.
プロトコルがAAAプロトコルを介して転送されることが予想される識別子を運ぶ場合、識別子はNAI形式であることが推奨されます。識別子がNAI形式ではない場合、これを発見して処理するのはAAAシステム次第です。このドキュメントでは、その方法を提案していません。しかし、既存の慣行はそれが可能であることを示しています。
As internationalized domain names become more widely used, existing practices are likely to become inadequate. This document therefore defines the NAI, which is a user identifier format that can correctly deal with internationalized identifiers.
国際化ドメイン名がより広く使用されるようになると、既存の慣行は不適切になる可能性があります。したがって、このドキュメントでは、国際化された識別子を正しく処理できるユーザー識別子形式であるNAIを定義します。
The grammar for the NAI is given below, described in Augmented Backus-Naur Form (ABNF) as documented in [RFC5234].
[RFC5234]に文書化されているように、NAIの文法を以下に示します。拡張バッカスナウアフォーム（ABNF）で説明されています。
nai = utf8-username
nai =/ "@" utf8-realm
nai =/ utf8-username "@" utf8-realm
utf8-username = dot-string
dot-string = string *("." string)
string = 1*utf8-atext
utf8-atext = ALPHA / DIGIT /
"!" / "#" /
"$" / "%" /
"&" / "'" /
"*" / "+" /
"-" / "/" /
"=" / "?" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
"~" /
UTF8-xtra-char
utf8-realm = 1*( label "." ) label
label = utf8-rtext *(ldh-str)
ldh-str = *( utf8-rtext / "-" ) utf8-rtext
utf8-rtext = ALPHA / DIGIT / UTF8-xtra-char
Devices handling NAIs MUST support an NAI length of at least 72 octets. Devices SHOULD support an NAI length of 253 octets. However, the following implementation issues should be considered:
NAIを処理するデバイスは、少なくとも72オクテットのNAI長をサポートする必要があります。デバイスは、253オクテットのNAI長をサポートする必要があります（SHOULD）。ただし、次の実装の問題を考慮する必要があります。
* NAI octet length constraints may impose a more severe constraint on the number of UTF-8 characters.
* NAIオクテット長の制約により、UTF-8文字の数により厳しい制約が課される場合があります。
* NAIs are often transported in the User-Name attribute of the Remote Authentication Dial-In User Service (RADIUS) protocol. Unfortunately, [RFC2865], Section 5.1 states that "the ability to handle at least 63 octets is recommended." As a result, it may not be possible to transfer NAIs beyond 63 octets through all devices. In addition, since only a single User-Name attribute may be included in a RADIUS message and the maximum attribute length is 253 octets, RADIUS is unable to support NAI lengths beyond 253 octets.
* NAIは、多くの場合、リモート認証ダイヤルインユーザーサービス（RADIUS）プロトコルのユーザー名属性で転送されます。残念ながら、[RFC2865]のセクション5.1には、「少なくとも63オクテットを処理する機能が推奨されている」と記載されています。その結果、63オクテットを超えるNAIをすべてのデバイスで転送できない場合があります。さらに、RADIUSメッセージに含めることができるUser-Name属性は1つだけで、属性の最大長は253オクテットであるため、RADIUSは253オクテットを超えるNAI長をサポートできません。
* NAIs can also be transported in the User-Name attribute of Diameter [RFC6733], which supports content lengths up to 2^24 - 9 octets. As a result, NAIs processed only by Diameter nodes can be very long. However, an NAI transported over Diameter may eventually be translated to RADIUS, in which case the above limitations will apply.
* NAIは、Diameter [RFC6733]のUser-Name属性でも転送できます。これは、最大2 ^ 24-9オクテットのコンテンツ長をサポートします。その結果、Diameterノードでのみ処理されるNAIは非常に長くなる可能性があります。ただし、Diameterを介して転送されたNAIは最終的にRADIUSに変換される可能性があります。その場合、上記の制限が適用されます。
* NAIs may be transported in other protocols. Each protocol can have its own limitations on maximum NAI length.
* NAIは他のプロトコルで転送できます。各プロトコルには、最大NAI長に独自の制限があります。
The above criteria should permit the widest use and widest possible interoperability of the NAI.
上記の基準は、NAIの最も幅広い使用と可能な限り幅広い相互運用性を可能にするはずです。
Interpretation of the username part of the NAI depends on the realm in question. Therefore, the utf8-username portion SHOULD be treated as opaque data when processed by nodes that are not a part of the home domain for that realm.
NAIのユーザー名部分の解釈は、問題の領域によって異なります。したがって、そのレルムのホームドメインの一部ではないノードによって処理される場合、utf8-username部分は不透明なデータとして扱われる必要があります（SHOULD）。
That is, the only domain that is capable of interpreting the meaning of the utf8-username portion of the NAI is the home domain. Any third-party domains cannot form any conclusions about the utf8-username and cannot decode it into subfields. For example, it may be used as "firstname.lastname", or it may be entirely digits, or it may be a random hex identifier. There is simply no way (and no reason) for any other domain to interpret the utf8-username field as having any meaning whatsoever.
つまり、NAIのutf8-username部分の意味を解釈できる唯一のドメインはホームドメインです。サードパーティのドメインでは、utf8-usernameについて結論を出すことはできず、サブフィールドにデコードすることもできません。たとえば、「firstname.lastname」として使用することも、完全に数字にすることも、ランダムな16進数の識別子にすることもできます。他のドメインがutf8-usernameフィールドをなんらかの意味を持つと解釈する方法（および理由）はありません。
In some situations, NAIs are used together with a separate authentication method that can transfer the username part in a more secure manner to increase privacy. In this case, NAIs MAY be provided in an abbreviated form by omitting the username part. Omitting the username part is RECOMMENDED over using a fixed username part, such as "anonymous", since including a fixed username part is ambiguous as to whether or not the NAI refers to a single user. However, current practice is to use the username "anonymous" instead of omitting the username part. This behavior is also permitted.
状況によっては、NAIは、プライバシーを高めるためにより安全な方法でユーザー名の部分を転送できる個別の認証方法と共に使用されます。この場合、ユーザー名の部分を省略して、NAIを省略形で提供できます。 NAIが単一のユーザーを参照するかどうかについては、固定ユーザー名の部分を含めることはあいまいであるため、「匿名」などの固定ユーザー名の部分を使用するよりも、ユーザー名の部分を省略することをお勧めします。ただし、現在のところ、ユーザー名の部分を省略する代わりに、「匿名」のユーザー名を使用しています。この動作も許可されています。
The most common use case of omitting or obfuscating the username part is with TLS-based EAP methods such as Tunneled Transport Layer Security (TTLS) [RFC5281]. Those methods allow for an "outer" identifier, which is typically an anonymous "@realm". This outer identifier allows the authentication request to be routed from a visited domain to a home domain. At the same time, the username part is kept confidential from the visited network. The protocol provides for an "inner" authentication exchange, in which a full identifier is used to authenticate a user.
ユーザー名の部分を省略または難読化する最も一般的な使用例は、Tunneled Transport Layer Security（TTLS）[RFC5281]などのTLSベースのEAPメソッドを使用する場合です。これらのメソッドは、通常は匿名の「@realm」である「外部」識別子を許可します。この外部識別子により、認証要求を訪問済みドメインからホームドメインにルーティングできます。同時に、ユーザー名の部分は訪問したネットワークから機密に保たれます。このプロトコルは、完全な識別子を使用してユーザーを認証する「内部」認証交換を提供します。
That scenario offers the best of both worlds. An anonymous NAI can be used to route authentication to the home domain, and the home domain has sufficient information to identify and authenticate users.
そのシナリオは、両方の長所を提供します。匿名NAIを使用してホームドメインに認証をルーティングできます。ホームドメインには、ユーザーを識別および認証するための十分な情報があります。
However, some protocols do not support authentication methods that allow for "inner" and "outer" exchanges. Those protocols are limited to using an identifier that is publicly visible. It is therefore RECOMMENDED that such protocols use ephemeral identifiers. We recognize that this practice is not currently used and will likely be difficult to implement.
ただし、一部のプロトコルは、「内部」および「外部」交換を可能にする認証方法をサポートしていません。これらのプロトコルは、公開されている識別子の使用に限定されています。したがって、このようなプロトコルは一時的な識別子を使用することをお勧めします。この手法は現在使用されておらず、実装するのが難しいと思われます。
Similar to the anonymous user, there may be situations where portions of the realm are sensitive. For those situations, it is RECOMMENDED that the sensitive portion of the realm also be omitted (e.g., to use "@example.com" instead of "@sensitive.example.com", or "anonymous@sensitive.example.com"). The home domain is authoritative for users in all subdomains and can (if necessary) route the authentication request to the appropriate subsystem within the home domain.
匿名ユーザーと同様に、レルムの一部が機密である場合があります。これらの状況では、レルムの機密部分も省略することをお勧めします（たとえば、「@ sensitive.example.com」または「anonymous@sensitive.example.com」の代わりに「@ example.com」を使用するには） 。ホームドメインはすべてのサブドメインのユーザーに権限があり、（必要な場合）認証要求をホームドメイン内の適切なサブシステムにルーティングできます。
For roaming purposes, it is typically necessary to locate the appropriate backend authentication server for the given NAI before the authentication conversation can proceed. As a result, authentication routing is impossible unless the realm portion is available and is in a well-known format.
ローミングの目的では、認証の会話を進める前に、通常、特定のNAIに適切なバックエンド認証サーバーを見つける必要があります。その結果、レルム部分が使用可能であり、既知の形式でない限り、認証ルーティングは不可能です。
This specification allows both international usernames and realms. International usernames are based on the use of Unicode characters, encoded as UTF-8. Internationalization of the username portion of the NAI is based on the "Internationalized Email Headers" [RFC6532] extensions to the "local-part" portion of email addresses [RFC5322].
この仕様では、国際的なユーザー名とレルムの両方を使用できます。国際的なユーザー名は、UTF-8としてエンコードされたUnicode文字の使用に基づいています。 NAIのユーザー名部分の国際化は、電子メールアドレスの[local-part]部分の[国際化された電子メールヘッダー] [RFC6532]拡張[RFC5322]に基づいています。
In order to ensure a canonical representation, characters of the realm portion in an NAI MUST match the ABNF in this specification as well as the requirements specified in [RFC5891]. In practice, these requirements consist of the following item:
正規表現を保証するために、NAIのレルム部分の文字は、この仕様のABNFと、[RFC5891]で指定された要件に一致する必要があります。実際には、これらの要件は次の項目で構成されています。
* Realms MUST be of the form that can be registered as a Fully Qualified Domain Name (FQDN) within the DNS.
* レルムは、DNS内の完全修飾ドメイン名（FQDN）として登録できる形式である必要があります。
This list is significantly shorter and simpler than the list in Section 2.4 of [RFC4282]. The form suggested in [RFC4282] depended on intermediate nodes performing canonicalizations based on insufficient information, which meant that the form was not canonical.
このリストは、[RFC4282]のセクション2.4のリストよりも大幅に短くシンプルです。 [RFC4282]で提案されたフォームは、不十分な情報に基づいて正規化を実行する中間ノードに依存していたため、フォームは正規ではありませんでした。
Specifying the realm requirement as above means that the requirements depend on specifications that are referenced here, rather than copied here. This allows the realm definition to be updated when the referenced documents change, without requiring a revision of this specification.
上記のようにレルム要件を指定すると、要件はここにコピーされるのではなく、ここで参照される仕様に依存します。これにより、この仕様の改訂を必要とせずに、参照されるドキュメントが変更されたときにレルム定義を更新できます。
One caveat on the above recommendation is the issues noted in [RFC6912]. That document notes that there are additional restrictions around DNS registration that forbid some code points from being valid in a DNS U-label. These restrictions cannot be expressed algorithmically.
上記の推奨事項に関する1つの警告は、[RFC6912]に記載されている問題です。その文書は、DNS Uラベルで一部のコードポイントが有効になることを禁止するDNS登録の周りに追加の制限があることを注記しています。これらの制限はアルゴリズム的に表現することはできません。
For this specification, that caveat means the following: Realms not matching the above ABNF are not valid NAIs. However, some realms that do match the ABNF are still invalid NAIs. That is, matching the ABNF is a necessary, but not sufficient, requirement for an NAI.
この仕様では、警告は次のことを意味します。上記のABNFに一致しないレルムは有効なNAIではありません。ただし、ABNFと一致する一部のレルムは依然として無効なNAIです。つまり、ABNFを一致させることは、NAIの必要条件ではありますが、十分ではありません。
In general, the above requirement means following the requirements specified in [RFC5891].
一般に、上記の要件は、[RFC5891]で指定された要件に従うことを意味します。
Conversion to Unicode as well as normalization SHOULD be performed by edge systems (e.g., laptops, desktops, smart phones, etc.) that take "local" text as input. These edge systems are best suited to determine the user's intent and can best convert from "local" text to a normalized form.
Unicodeへの変換と正規化は、「ローカル」テキストを入力として受け取るエッジシステム（ラップトップ、デスクトップ、スマートフォンなど）で実行する必要があります（SHOULD）。これらのエッジシステムは、ユーザーの意図を判断するのに最適であり、「ローカル」テキストから正規化された形式に変換するのに最適です。
Other AAA systems such as proxies do not have access to locale and character set information that is available to edge systems. Therefore, they may not always be able to convert local input to Unicode.
プロキシなどの他のAAAシステムは、エッジシステムで使用できるロケールおよび文字セット情報にアクセスできません。したがって、ローカル入力をUnicodeに変換できるとは限りません。
That is, all processing of NAIs from "local" character sets and locales to UTF-8 SHOULD be performed by edge systems, prior to the NAIs entering the AAA system. Inside of a AAA system, NAIs are sent over the wire in their canonical form, and this canonical form is used for all NAI and/or realm comparisons.
つまり、「ローカル」の文字セットとロケールからUTF-8へのNAIのすべての処理は、NAIがAAAシステムに入る前に、エッジシステムで実行する必要があります（SHOULD）。 AAAシステムの内部では、NAIは標準形式でネットワーク経由で送信され、この標準形式はすべてのNAIやレルムの比較に使用されます。
Copying of localized text into fields that can subsequently be placed into the RADIUS User-Name attribute is problematic. This practice can result in a AAA proxy encountering non-UTF-8 characters within what it expects to be an NAI. An example of this requirement is Section 2.1 of [RFC3579], which states:
ローカライズされたテキストを、後でRADIUSのユーザー名属性に配置できるフィールドにコピーすると、問題が発生します。この方法では、NAAであると予期される範囲内でAAAプロキシが非UTF-8文字に遭遇する可能性があります。この要件の例は、[RFC3579]のセクション2.1で、次のように述べられています。
the NAS MUST copy the contents of the Type-Data field of the EAP-Response/Identity received from the peer into the User-Name attribute
NASは、ピアから受信したEAP-Response / IdentityのType-Dataフィールドの内容をUser-Name属性にコピーする必要があります
As a result, AAA proxies expect the contents of the EAP-Response/Identity sent by an EAP supplicant to consist of UTF-8 characters, not localized text. Using localized text in AAA username or identity fields means that realm routing becomes difficult or impossible.
その結果、AAAプロキシは、EAPサプリカントによって送信されたEAP-Response / IdentityのコンテンツがローカライズされたテキストではなくUTF-8文字で構成されることを期待します。 AAAユーザー名またはIDフィールドでローカライズされたテキストを使用すると、レルムルーティングが困難または不可能になります。
In contrast to Section 2.4 of [RFC4282], AAA systems are now expected to perform NAI comparisons, matching, and AAA routing based on the NAI as it is received. This specification provides a canonical representation, ensures that intermediate AAA systems such as proxies are not required to perform translations, and can be expected to work through AAA systems that are unaware of international character sets.
[RFC4282]のセクション2.4とは対照的に、AAAシステムは、受信したNAIに基づいて、NAI比較、マッチング、およびAAAルーティングを実行することが期待されています。この仕様は標準的な表現を提供し、プロキシなどの中間AAAシステムが変換を実行する必要がないことを保証し、国際的な文字セットを認識しないAAAシステムを通じて機能することが期待できます。
In an ideal world, the following requirements would be widely implemented:
理想的な世界では、次の要件が広く実装されます。
* Edge systems using "localized" text SHOULD normalize the NAI prior to it being used as an identifier in an authentication protocol.
* 「ローカライズされた」テキストを使用するエッジシステムは、認証プロトコルで識別子として使用される前にNAIを正規化する必要があります。
* AAA systems SHOULD NOT normalize the NAI, as they may not have sufficient information to perform the normalization.
* AAAシステムは、正規化を実行するための十分な情報がない可能性があるため、NAIを正規化しないでください。
There are issues with this approach, however.
ただし、このアプローチには問題があります。
The requirements in the preceding section are not implemented today. For example, most EAP implementations use a user identifier that is passed to them from some other local system. This identifier is treated as an opaque blob and is placed as is into the EAP Identity field. Any subsequent system that receives that identifier is assumed to be able to understand and process it.
前のセクションの要件は現在実装されていません。たとえば、ほとんどのEAP実装は、他のローカルシステムから渡されたユーザー識別子を使用します。この識別子は不透明なblobとして扱われ、そのままEAP Identityフィールドに配置されます。その識別子を受け取る後続のシステムは、それを理解して処理できると想定されます。
This opaque blob unfortunately can contain localized text, which means that the AAA systems have to process that text.
あいにく、この不透明なblobにはローカライズされたテキストが含まれている可能性があります。つまり、AAAシステムはそのテキストを処理する必要があります。
These limitations have the following theoretical and practical implications:
これらの制限には、次の理論的および実用的な影響があります。
* Edge systems used today generally do not normalize the NAI.
* 現在使用されているエッジシステムは、通常、NAIを正規化しません。
* Therefore, AAA systems SHOULD attempt to normalize the NAI.
* したがって、AAAシステムはNAIの正規化を試みる必要があります。
The suggestions above contradict the suggestions in the previous section. This is the reality of imperfect protocols.
上記の提案は、前のセクションの提案と矛盾しています。これが不完全なプロトコルの現実です。
Where the user identifier can be normalized, or determined to be in normal form, the normal form MUST be used as the NAI. In all other circumstances, the user identifier MUST NOT be treated as an NAI. That data is still, however, a user identifier. AAA systems MUST NOT fail authentication simply because the user identifier is not an NAI.
ユーザー識別子を正規化できる、または通常の形式であると判断できる場合、NAIとして通常の形式を使用する必要があります。他のすべての状況では、ユーザー識別子をNAIとして扱わないでください。ただし、そのデータはユーザーIDです。 AAAシステムは、ユーザー識別子がNAIではないという理由だけで認証に失敗してはなりません（MUST NOT）。
That is, when the realm portion of the NAI is not recognized by a AAA server, it SHOULD try to normalize the NAI into NFC form. That normalized form can then be used to see if the realm matches a known realm. If no match is found, the original form of the NAI SHOULD be used in all subsequent processing.
つまり、NAIのレルム部分がAAAサーバーによって認識されない場合、NAIをNFC形式に正規化する必要があります。その正規化された形式を使用して、レルムが既知のレルムと一致するかどうかを確認できます。一致が見つからない場合は、その後のすべての処理でNAIの元の形式を使用する必要があります（SHOULD）。
The AAA server may also convert realms to Punycode and perform all realm comparisons on the resulting Punycode strings. This conversion follows the recommendations above but may have different operational effects and failure modes.
AAAサーバーは、レルムをPunycodeに変換し、結果のPunycode文字列に対してすべてのレルム比較を実行する場合もあります。この変換は、上記の推奨事項に従いますが、異なる操作上の影響と障害モードを持つ場合があります。
As noted earlier, the NAI format can be used in other, non-AAA protocols. It is RECOMMENDED that the definition given here be used unchanged. Using other definitions for user identifiers may hinder interoperability, along with the user's ability to authenticate successfully. It is RECOMMENDED that protocols requiring the use of a user identifier use the NAI format.
前述のように、NAI形式は他の非AAAプロトコルで使用できます。ここで与えられた定義を変更せずに使用することをお勧めします。ユーザーIDの他の定義を使用すると、ユーザーが正常に認証する機能とともに、相互運用性が妨げられる可能性があります。ユーザーIDの使用を必要とするプロトコルはNAI形式を使用することをお勧めします。
This document cannot require other protocols to use the NAI format for user identifiers. Their needs are unknown and, at this time, unknowable. This document suggests that interoperability and inter-domain authentication are useful and should be encouraged.
このドキュメントでは、ユーザー識別子にNAI形式を使用するために他のプロトコルを要求することはできません。彼らのニーズは不明であり、現時点では認識できません。このドキュメントは、相互運用性とドメイン間認証が有用であり、推奨されることを示唆しています。
Where a protocol is 8-bit clean, it can likely transport the NAI as is, without further modification.
プロトコルが8ビットクリーンである場合、さらに変更することなく、NAIをそのまま転送できる可能性があります。
Where a protocol is not 8-bit clean, it cannot transport the NAI as is. Instead, this document presumes that a protocol-specific transport layer takes care of encoding the NAI on input to the protocol and decoding it when the NAI exits the protocol. The encoded or escaped version of the NAI is not a valid NAI and MUST NOT be presented to the AAA system.
プロトコルが8ビットクリーンでない場合、NAIをそのまま転送できません。代わりに、このドキュメントでは、プロトコル固有のトランスポート層がプロトコルへの入力時にNAIをエンコードし、NAIがプロトコルを終了するときにデコードすることを前提としています。エンコードまたはエスケープされたバージョンのNAIは有効なNAIではなく、AAAシステムに提示してはなりません。
For example, HTTP carries user identifiers but escapes the '.' character as "%2E" (among others). When HTTP is used to transport the NAI "fred@example.com", the data as transported will be in the form "fred@example%2Ecom". That data exists only within HTTP and has no relevance to any AAA system.
たとえば、HTTPはユーザー識別子を伝達しますが、「。」をエスケープします。 （特に）「％2E」としての文字。 HTTPを使用してNAI「fred@example.com」を転送する場合、転送されるデータは「fred @ example％2Ecom」の形式になります。そのデータはHTTP内にのみ存在し、どのAAAシステムにも関連しません。
Any comparison, validation, or use of the NAI MUST be done on its unescaped (i.e., utf8-clean) form.
NAIの比較、検証、または使用は、エスケープされていない（つまり、utf8-clean）フォームで実行する必要があります。
As discussed in Section 1, above, it is RECOMMENDED that the NAI format be used as the standard format for user identifiers. This section discusses that use in more detail.
上記のセクション1で説明したように、ユーザー識別子の標準形式としてNAI形式を使用することをお勧めします。このセクションでは、その使用について詳しく説明します。
It is often useful to create new identifiers for use in specific contexts. These identifiers may have a number of different properties, most of which are unimportant to this document. The goal of this document is to create identifiers that are to be in a well-known format and that will have namespaces. The NAI format fits these requirements.
特定のコンテキストで使用する新しい識別子を作成すると便利な場合があります。これらの識別子にはさまざまなプロパティがあり、そのほとんどはこのドキュメントでは重要ではありません。このドキュメントの目的は、既知の形式であり、名前空間を持つ識別子を作成することです。 NAI形式はこれらの要件に適合します。
One example of such use is the "private user identity", which is an identifier defined by the 3rd Generation Partnership Project (3GPP). That identifier is used to uniquely identify the user to the network. The identifier is used for authorization, authentication, accounting, administration, etc. The "private user identity" is globally unique and is defined by the home network operator. The format of the identifier is explicitly the NAI, as stated by Section 13.3 of [3GPP]:
そのような使用の1つの例は、「プライベートユーザーID」です。これは、第3世代パートナーシッププロジェクト（3GPP）によって定義された識別子です。その識別子は、ネットワークに対してユーザーを一意に識別するために使用されます。識別子は、承認、認証、アカウンティング、管理などに使用されます。「プライベートユーザーID」はグローバルに一意であり、ホームネットワークオペレーターによって定義されます。 [3GPP]のセクション13.3で述べられているように、識別子の形式は明示的にNAIです。
The private user identity shall take the form of an NAI, and shall have the form username@realm as specified in clause 2.1 of IETF RFC 4282
プライベートユーザーIDは、NAIの形式をとる必要があり、IETF RFC 4282の2.1節で指定されているように、username @ realmの形式を持っている必要があります。
For 3GPP, the "username" portion is a unique identifier that is derived from device-specific information. The "realm" portion is composed of information about the home network, followed by the base string "3gppnetwork.org" (e.g., 234150999999999@ims.mnc015.mcc234.3gppnetwork.org).
3GPPの場合、「ユーザー名」の部分は、デバイス固有の情報から派生した一意の識別子です。 「レルム」部分は、ホームネットワークに関する情報と、その後に続くベース文字列「3gppnetwork.org」（234150999999999@ims.mnc015.mcc234.3gppnetwork.orgなど）で構成されています。
This format as defined by 3GPP ensures that the identifier is globally unique, as it is based on the "3gppnetwork.org" domain. It ensures that the "realm" portion is specific to a particular home network (or organization), via the "ims.mnc015.mcc234" prefix to the realm. Finally, it ensures that the "username" portion follows a well-known format.
3GPPで定義されているこの形式は、「3gppnetwork.org」ドメインに基づいているため、識別子がグローバルに一意であることを保証します。 「レム」部分は、レルムへの「ims.mnc015.mcc234」プレフィックスを介して、特定のホームネットワーク（または組織）に固有であることを保証します。最後に、「ユーザー名」の部分がよく知られている形式に従うようにします。
This document suggests that the NAI format be used for all new specifications and/or protocols where a user identifier is required. Where the username portions need to be created with subfields, a well-known and documented method, as has been done with 3GPP, is preferred to ad hoc methods.
このドキュメントでは、ユーザーIDが必要なすべての新しい仕様やプロトコルにNAI形式を使用することを推奨しています。ユーザー名の部分をサブフィールドで作成する必要がある場合、3GPPで行われたように、よく知られて文書化されている方法が、アドホックな方法よりも推奨されます。
Many AAA systems use the "utf8-realm" portion of the NAI to route requests within a AAA proxy network. The semantics of this operation involves a logical AAA routing table, where the "utf8-realm" portion acts as a key, and the values stored in the table are one or more "next hop" AAA servers.
多くのAAAシステムは、NAIの「utf8-realm」部分を使用して、AAAプロキシネットワーク内でリクエストをルーティングします。この操作のセマンティクスには、論理AAAルーティングテーブルが含まれます。この場合、「utf8-realm」部分がキーとして機能し、テーブルに格納される値は1つ以上の「ネクストホップ」AAAサーバーです。
Intermediate nodes MUST use the "utf8-realm" portion of the NAI without modification to perform this lookup. As noted earlier, intermediate nodes may not have access to the same locale information as the system that injected the NAI into the AAA routing systems. Therefore, almost all "case insensitive" comparisons can be wrong. Where the "utf8-realm" is entirely ASCII, current AAA systems sometimes perform case-insensitive matching on realms. This method MAY be continued, as it has been shown to work in practice.
中間ノードは、このルックアップを実行するために変更せずにNAIの「utf8-realm」部分を使用する必要があります。前述のように、中間ノードは、NAIをAAAルーティングシステムに挿入したシステムと同じロケール情報にアクセスできない場合があります。したがって、ほとんどすべての「大文字と小文字を区別しない」比較は間違っている可能性があります。 「utf8-レルム」が完全にASCIIである場合、現在のAAAシステムはレルムに対して大文字と小文字を区別しないマッチングを実行することがあります。この方法は、実際に機能することが示されているため、続行することができます。
Many existing non-AAA systems have user identifiers that are similar in format to the NAI but that are not compliant with this specification. For example, they may use non-NFC form, or they may have multiple "@" characters in the user identifier. Intermediate nodes SHOULD normalize non-NFC identifiers to NFC, prior to looking up the "utf8-realm" in the logical routing table. Intermediate nodes MUST NOT modify the identifiers that they forward. The data as entered by the user is inviolate.
多くの既存の非AAAシステムには、形式がNAIに似ていますが、この仕様に準拠していないユーザー識別子があります。たとえば、NFC以外の形式を使用したり、ユーザー識別子に複数の「@」文字が含まれる場合があります。中間ノードは、論理ルーティングテーブルで「utf8レルム」を検索する前に、NFC以外の識別子をNFCに正規化する必要があります（SHOULD）。中間ノードは、転送する識別子を変更してはなりません。ユーザーが入力したデータは違反です。
The "utf8-realm" provisioned in the logical AAA routing table SHOULD be provisioned to the proxy prior to it receiving any AAA traffic. The "utf8-realm" SHOULD be supplied by the "next hop" or "home" system that also supplies the routing information necessary for packets to reach the next hop.
論理AAAルーティングテーブルでプロビジョニングされた「utf8レルム」は、AAAトラフィックを受信する前にプロキシにプロビジョニングする必要があります（SHOULD）。 「utf8-realm」は、パケットがネクストホップに到達するために必要なルーティング情報も提供する「ネクストホップ」または「ホーム」システムによって提供される必要があります（SHOULD）。
This "next hop" information may be any of, or all of, the following information: IP address, port, RADIUS shared secret, TLS certificate, DNS host name, or instruction to use dynamic DNS discovery (i.e., look up a record in the "utf8-realm" domain). This list is not exhaustive and may be extended by future specifications.
この「ネクストホップ」情報は、IPアドレス、ポート、RADIUS共有シークレット、TLS証明書、DNSホスト名、または動的DNS検出を使用するための指示（つまり、 「utf8-realm」ドメイン）。このリストは完全なものではなく、将来の仕様によって拡張される可能性があります。
It is RECOMMENDED to use the entirety of the "utf8-realm" for the routing decisions. However, AAA systems MAY use a portion of the "utf8-realm" portion, so long as that portion is a valid "utf8-realm" and is handled as above. For example, routing "fred@example.com" to a "com" destination is forbidden, because "com" is not a valid "utf8-realm". However, routing "fred@sales.example.com" to the "example.com" destination is permissible.
ルーティングの決定には、「utf8レルム」全体を使用することをお勧めします。しかし、AAAシステムは、その部分が有効な「utf8-realm」であり、上記のように処理される限り、「utf8-realm」部分の一部を使用する場合があります。たとえば、「com」は有効な「utf8-realm」ではないため、「fred@example.com」を「com」宛先にルーティングすることは禁止されています。ただし、「fred@sales.example.com」を「example.com」宛先にルーティングすることは許可されています。
Another reason to forbid the use of a single label (e.g., "fred@sales") is that many non-AAA systems treat a single label as being a local identifier within their realm. That is, a user logging in as "fred@sales" to a domain "example.com" would be treated as if the NAI was instead "fred@sales.example.com". Permitting the use of a single label would mean changing the interpretation and meaning of a single label, which cannot be done.
単一ラベルの使用を禁止するもう1つの理由（「fred @ sales」など）は、多くの非AAAシステムが単一ラベルをレルム内のローカル識別子として扱うためです。つまり、「fred @ sales」としてドメイン「example.com」にログインするユーザーは、NAIが「fred@sales.example.com」であるかのように扱われます。単一のラベルの使用を許可することは、単一のラベルの解釈と意味を変更することを意味しますが、これは実行できません。
As proposed in this document, the Network Access Identifier is of the form "user@realm". Please note that while the user portion of the NAI is based on the "Internet Message Format" [RFC5322] "local-part" portion of an email address as extended by "Internationalized Email Headers" [RFC6532], it has been modified for the purposes of Section 2.2. It does not permit quoted text along with "folding" or "non-folding" whitespace that is commonly used in email addresses. As such, the NAI is not necessarily equivalent to usernames used in email.
このドキュメントで提案されているように、ネットワークアクセス識別子は「user @ realm」の形式です。 NAIのユーザー部分は「インターネットメッセージ形式」[RFC5322]に基づいていますが、「国際化電子メールヘッダー」[RFC6532]によって拡張された電子メールアドレスの「ローカル部分」部分は、セクション2.2の目的。電子メールアドレスで一般的に使用される「折りたたみ」または「折りたたみなし」の空白とともに引用符で囲まれたテキストは許可されません。そのため、NAIは、電子メールで使用されるユーザー名と必ずしも同等ではありません。
However, it is a common practice to use email addresses as user identifiers in AAA systems. The ABNF in Section 2.2 is defined to be close to the "addr-spec" portion of [RFC5322] as extended by [RFC6532], while still being compatible with [RFC4282].
ただし、AAAシステムではユーザーIDとしてメールアドレスを使用するのが一般的です。セクション2.2のABNFは、[RFC6532]によって拡張された[RFC5322]の「addr-spec」部分に近いと定義されていますが、[RFC4282]との互換性は維持されています。
In contrast to Section 2.5 of [RFC4282], this document states that the internationalization requirements for NAIs and email addresses are substantially similar. The NAI and email identifiers may be the same, and both need to be entered by the user and/or the operator supplying network access to that user. There is therefore good reason for the internationalization requirements to be similar.
[RFC4282]のセクション2.5とは対照的に、このドキュメントでは、NAIとメールアドレスの国際化要件は実質的に類似していると述べています。 NAIと電子メールの識別子は同じである可能性があり、両方ともユーザーおよび/またはそのユーザーにネットワークアクセスを提供するオペレーターが入力する必要があります。したがって、国際化要件が同様であることには十分な理由があります。
The "utf8-realm" portion of the NAI is intended to be compatible with Internationalized Domain Names (IDNs) [RFC5890]. As defined above, the "utf8-realm" portion as transported within an 8-bit clean protocol such as RADIUS and EAP can contain any valid UTF-8 character. There is therefore no reason for a NAS to convert the "utf8-realm" portion of an NAI into Punycode encoding form [RFC3492] prior to placing the NAI into a RADIUS User-Name attribute.
NAIの「utf8-realm」部分は、国際化ドメイン名（IDN）[RFC5890]との互換性を目的としています。上で定義したように、RADIUSやEAPなどの8ビットのクリーンプロトコル内で転送される「utf8-realm」部分には、有効なUTF-8文字を含めることができます。したがって、NAIをRADIUS User-Name属性に配置する前に、NASがNAIの「utf8-realm」部分をPunycodeエンコード形式[RFC3492]に変換する理由はありません。
The NAI does not make a distinction between A-labels and U-labels, as those are terms specific to DNS. It is instead an IDNA-valid label, as per the first item in Section 2.3.2.1 of [RFC5890]. As noted in that section, the term "IDNA-valid label" encompasses both "A-label" and "U-label".
NAIは、AラベルとUラベルを区別しません。これらはDNSに固有の用語であるためです。 [RFC5890]のセクション2.3.2.1の最初の項目にあるように、代わりにIDNA有効なラベルです。そのセクションで述べたように、「IDNA有効ラベル」という用語は、「Aラベル」と「Uラベル」の両方を含みます。
When the realm portion of the NAI is used as the basis for name resolution, it may be necessary to convert internationalized realm names to Punycode [RFC3492] encoding form as described in [RFC5891]. As noted in Section 2 of [RFC6055], resolver Application Programming Interfaces (APIs) are not necessarily DNS specific, so conversion to Punycode needs to be done carefully:
NAIのレルム部分が名前解決の基礎として使用される場合、[RFC5891]で説明されているように、国際化されたレルム名をPunycode [RFC3492]エンコード形式に変換する必要がある場合があります。 [RFC6055]のセクション2で述べたように、リゾルバーアプリケーションプログラミングインターフェース（API）は必ずしもDNS固有ではないため、Punycodeへの変換は慎重に行う必要があります。
Applications that convert an IDN to A-label form before calling (for example) getaddrinfo() will result in name resolution failures if the Punycode name is directly used in such protocols. Having libraries or protocols to convert from A-labels to the encoding scheme defined by the protocol (e.g., UTF-8) would require changes to APIs and/or servers, which Internationalized Domain Names for Applications (IDNA) was intended to avoid.
（たとえば）getaddrinfo()を呼び出す前にIDNをAラベル形式に変換するアプリケーションは、Punycode名がそのようなプロトコルで直接使用されている場合、名前解決に失敗します。ライブラリーまたはプロトコルをAラベルからプロトコル（UTF-8など）によって定義されたエンコード方式に変換するには、APIやサーバーを変更する必要があります。これは、アプリケーションの国際化ドメイン名（IDNA）が回避することを目的としていました。
As a result, applications SHOULD NOT assume that non-ASCII names are resolvable using the public DNS and blindly convert them to A-labels without knowledge of what protocol will be selected by the name resolution library.
結果として、アプリケーションは、非DNS名がパブリックDNSを使用して解決可能であると想定してはならず、名前解決ライブラリによってどのプロトコルが選択されるかを知らなくても、それらを盲目的にAラベルに変換する必要があります。
The home realm usually appears in the "utf8-realm" portion of the NAI, but in some cases a different realm can be used. This may be useful, for instance, when the home realm is reachable only via intermediate proxies.
ホームレルムは通常、NAIの「utf8-realm」部分に表示されますが、別のレルムを使用できる場合もあります。これは、たとえば、ホームレルムが中間プロキシを介してのみ到達可能である場合に役立ちます。
Such usage may prevent interoperability unless the parties involved have a mutual agreement that the usage is allowed. In particular, NAIs MUST NOT use a different realm than the home realm unless the sender has explicit knowledge that (a) the specified other realm is available and (b) the other realm supports such usage. The sender may determine the fulfillment of these conditions through a database, dynamic discovery, or other means not specified here. Note that the first condition is affected by roaming, as the availability of the other realm may depend on the user's location or the desired application.
このような使用は、関係者が使用が許可されているという相互の合意がない限り、相互運用性を妨げる可能性があります。特に、NAIは、送信者が（a）指定された他のレルムが利用可能であり、かつ（b）他のレルムがそのような使用法をサポートしていることを明確に知らない限り、ホームレルムとは異なるレルムを使用してはならない（MUST NOT）。送信者は、データベース、動的検出、またはここで指定されていないその他の手段を通じて、これらの条件を満たすかどうかを判断できます。他のレルムの可用性はユーザーの場所または目的のアプリケーションに依存する可能性があるため、最初の条件はローミングの影響を受けることに注意してください。
The use of the home realm MUST be the default unless otherwise configured.
特に設定されていない限り、ホームレルムの使用がデフォルトでなければなりません。
Some AAA systems have historically used NAI modifications with multiple "prefix" and "suffix" decorations to perform explicit routing through multiple proxies inside of a AAA network.
一部のAAAシステムは、AAAネットワーク内の複数のプロキシを介して明示的なルーティングを実行するために、複数の「プレフィックス」と「サフィックス」の装飾を伴うNAI変更を歴史的に使用してきました。
In RADIUS-based environments, the use of decorated NAI is NOT RECOMMENDED for the following reasons:
RADIUSベースの環境では、次の理由により、装飾されたNAIの使用は推奨されません。
* Using explicit routing paths is fragile and is unresponsive to changes in the network due to servers going up or down or to changing business relationships.
* 明示的なルーティングパスの使用は脆弱であり、サーバーの稼働や停止によるビジネスの変化やネットワークの変化には反応しません。
* There is no RADIUS routing protocol, meaning that routing paths have to be communicated "out of band" to all intermediate AAA nodes, and also to all edge systems (e.g., supplicants) expecting to obtain network access.
* RADIUSルーティングプロトコルはありません。つまり、ルーティングパスは、すべての中間AAAノードと、ネットワークアクセスを取得することを期待しているすべてのエッジシステム（サプリカントなど）に「帯域外」で通信する必要があります。
* Using explicit routing paths requires thousands, if not millions, of edge systems to be updated with new path information when a AAA routing path changes. This adds huge expense for updates that would be better done at only a few AAA systems in the network.
* 明示的なルーティングパスを使用するには、AAAルーティングパスが変更されたときに、数百万ではなくても数千のエッジシステムを新しいパス情報で更新する必要があります。これは、ネットワーク内のいくつかのAAAシステムでのみ実行するほうがよい更新に莫大な費用を追加します。
* Manual updates to RADIUS paths are expensive, time-consuming, and prone to error.
* RADIUSパスを手動で更新すると、コストがかかり、時間がかかり、エラーが発生しやすくなります。
* Creating compatible formats for the NAI is difficult when locally defined "prefixes" and "suffixes" conflict with similar practices elsewhere in the network. These conflicts mean that connecting two networks may be impossible in some cases, as there is no way for packets to be routed properly in a way that meets all requirements at all intermediate proxies.
* ローカルで定義された「プレフィックス」と「サフィックス」がネットワークの他の場所で同様の方法と競合する場合、NAIの互換性のあるフォーマットを作成することは困難です。これらの競合は、すべての中間プロキシのすべての要件を満たす方法でパケットを適切にルーティングする方法がないため、2つのネットワークを接続できない場合があることを意味します。
* Leveraging the DNS name system for realm names establishes a globally unique namespace for realms.
* DNSネームシステムをレルム名に利用すると、レルムにグローバルに一意のネームスペースが確立されます。
In summary, network practices and capabilities have changed significantly since NAIs were first overloaded to define AAA routes through a network. While manually managed explicit path routing was once useful, the time has come for better methods to be used.
要約すると、ネットワークを介してAAAルートを定義するためにNAIが最初に過負荷になったため、ネットワークのプラクティスと機能は大幅に変更されました。手動で管理された明示的なパスルーティングはかつて有用でしたが、より良い方法を使用する時が来ました。
Notwithstanding the above recommendations, the above practice is widely used for Diameter routing [RFC5729]. The routes described there are managed automatically, for both credential provisioning and routing updates. Those routes also exist within a particular framework (typically 3G), where membership is controlled and system behavior is standardized. There are no known issues with using explicit routing in such an environment.
上記の推奨事項にもかかわらず、上記の方法はDiameterルーティング[RFC5729]で広く使用されています。そこで説明されているルートは、資格情報のプロビジョニングとルーティングの更新の両方で自動的に管理されます。これらのルートは、メンバーシップが制御され、システムの動作が標準化されている特定のフレームワーク（通常は3G）内にも存在します。このような環境で明示的なルーティングを使用する場合の既知の問題はありません。
However, if decorated identifiers are used, such as:
ただし、次のような装飾された識別子が使用されている場合：
homerealm.example.org!user@otherrealm.example.net
ほめれあｌｍ。えぁｍｐぇ。おｒｇ！うせｒ＠おてぇっれあｌｍ。えぁｍｐぇ。ねｔ
then the part before the (non-escaped) '!' MUST be a "utf8-realm" as defined in the ABNF in Section 2.2. When receiving such an identifier, the "otherrealm.example.net" system MUST convert the identifier to "user@homerealm.example.org" before forwarding the request. The forwarding system MUST then apply normal AAA routing for the transaction, based on the updated identifier.
次に、（エスケープされていない）「！」の前の部分セクション2.2のABNFで定義されている「utf8-realm」でなければなりません。そのような識別子を受け取るとき、「otherrealm.example.net」システムはリクエストを転送する前に識別子を「user@homerealm.example.org」に変換しなければなりません。次に、転送システムは、更新された識別子に基づいて、トランザクションに通常のAAAルーティングを適用する必要があります。
Examples of valid Network Access Identifiers include the following:
有効なネットワークアクセス識別子の例は次のとおりです。
bob
joe@example.com
fred@foo-9.example.com
jack@3rd.depts.example.com
fred.smith@example.com
fred_smith@example.com
fred$@example.com
fred=?#$&*+-/^smith@example.com
nancy@eng.example.net
eng.example.net!nancy@example.net
eng%nancy@example.net
@privatecorp.example.net
\(user\)@example.net
An additional valid NAI is the following -- shown here as a hex string, as this document can only contain ASCII characters:
追加の有効なNAIは次のとおりです。このドキュメントにはASCII文字のみを含めることができるため、ここでは16進文字列として示しています。
626f 6240 ceb4 cebf ceba ceb9 cebc ceae 2e63 6f6d
626f 6240 ceb4 cebf ceba ceb9 cebc ceae 2e63 6f6d
Examples of invalid Network Access Identifiers include the following:
無効なネットワークアクセス識別子の例は次のとおりです。
fred@example
fred@example_9.com
fred@example.net@example.net
fred.@example.net
eng:nancy@example.net
eng;nancy@example.net
(user)@example.net
<nancy>@example.net
One example given in [RFC4282] is still permitted by the ABNF, but it is NOT RECOMMENDED because of the use of the Punycode [RFC3492] encoding form for what is now a valid UTF-8 string:
[RFC4282]に示されている1つの例は、ABNFでも許可されていますが、現在有効なUTF-8文字列にPunycode [RFC3492]エンコード形式を使用しているため、推奨されません。
alice@xn--tmonesimerkki-bfbb.example.net
あぃせ＠んーーｔもねしめｒっきーｂｆっｂ。えぁｍｐぇ。ねｔ
Since an NAI reveals the home affiliation of a user, it may assist an attacker in further probing the username space. Typically, this problem is of most concern in protocols that transmit the username in clear-text across the Internet, such as in RADIUS [RFC2865] [RFC2866]. In order to prevent snooping of the username, protocols may use confidentiality services provided by protocols transporting them, such as RADIUS protected by IPsec [RFC3579] or Diameter protected by TLS [RFC6733].
NAIはユーザーの所属を明らかにするため、攻撃者がユーザー名スペースをさらに詳しく調査するのに役立つ場合があります。通常、この問題は、RADIUS [RFC2865] [RFC2866]などのように、ユーザー名をインターネット経由でクリアテキストで送信するプロトコルで最も懸念されます。ユーザー名のスヌーピングを防ぐために、プロトコルは、IPsecによって保護されたRADIUS [RFC3579]やTLSによって保護されたDiameter [RFC6733]など、プロトコルを転送するプロトコルによって提供される機密性サービスを使用する場合があります。
This specification adds the possibility of hiding the username part in the NAI, by omitting it. As discussed in Section 2.4, this is possible only when NAIs are used together with a separate authentication method that can transfer the username in a secure manner. In some cases, application-specific privacy mechanisms have also been used with NAIs. For instance, some EAP methods apply method-specific pseudonyms in the username part of the NAI [RFC3748]. While neither of these approaches can protect the realm part, their advantage over transport protection is that the privacy of the username is protected, even through intermediate nodes such as NASes.
この仕様は、NAIのユーザー名部分を省略することにより、非表示にする可能性を追加します。セクション2.4で説明したように、これは、ユーザー名を安全な方法で転送できる個別の認証方法と共にNAIが使用されている場合にのみ可能です。場合によっては、アプリケーション固有のプライバシーメカニズムもNAIで使用されています。たとえば、一部のEAPメソッドは、メソッド固有の仮名をNAIのユーザー名部分に適用します[RFC3748]。これらのアプローチはどちらもレルム部分を保護できませんが、トランスポート保護に対するそれらの利点は、NASなどの中間ノードを介しても、ユーザー名のプライバシーが保護されることです。
The recommendations in Sections 2.7 and 2.8 for using the NAI in other protocols have implications for privacy. Any attacker who is capable of observing traffic containing the NAI can track the user and can correlate his activity across time and across multiple protocols. The authentication credentials therefore SHOULD be transported over channels that permit private communications, or multiple identifiers SHOULD be used, so that user tracking is impossible.
他のプロトコルでNAIを使用するためのセクション2.7および2.8の推奨事項は、プライバシーに影響を与えます。 NAIを含むトラフィックを監視できる攻撃者はすべて、ユーザーを追跡し、その活動を時間および複数のプロトコルにわたって関連付けることができます。したがって、認証資格情報は、プライベート通信を許可するチャネルを介して転送する必要があります（SHOULD）。または、ユーザー追跡が不可能になるように、複数の識別子を使用する必要があります。
It is RECOMMENDED that user privacy be enhanced by configuring multiple identifiers for one user. These identifiers can be changed over time, in order to make user tracking more difficult for a malicious observer. However, provisioning and management of the identifiers may be difficult to do in practice -- a likely reason why multiple identifiers are rarely used today.
1人のユーザーに複数の識別子を構成することにより、ユーザーのプライバシーを強化することをお勧めします。これらの識別子は、悪意のあるオブザーバーによるユーザー追跡をより困難にするために、時間の経過とともに変更される可能性があります。ただし、識別子のプロビジョニングと管理を実際に行うのは難しい場合があります。これは、今日、複数の識別子がほとんど使用されない理由と考えられます。
Section 1.3 states that multiple identifier formats allow attackers to make contradictory claims without being detected. This statement deserves further discussion.
セクション1.3では、複数の識別子形式により、攻撃者は検出されずに矛盾する主張を行うことができると述べています。このステートメントは、さらに議論する価値があります。
Section 2.4 discussed "inner" and "outer" identifiers in the context of TTLS [RFC5281]. A close reading of that specification shows there is no requirement that the inner and outer identifiers be in any way related. That is, it is perfectly valid to use "@example.com" for an outer identifier and "user@example.org" as an inner identifier. The authentication request will then be routed to "example.com", which will likely be unable to authenticate "user@example.org".
セクション2.4では、TTLS [RFC5281]のコンテキストでの「内部」および「外部」識別子について説明しました。その仕様をよく読むと、内部識別子と外部識別子が何らかの形で関連している必要はないことがわかります。つまり、外部識別子として「@ example.com」を使用し、内部識別子として「user@example.org」を使用することは完全に有効です。その後、認証リクエストは「example.com」にルーティングされ、「user@example.org」を認証できない可能性があります。
Even worse, a misconfiguration of "example.com" means that it may in turn proxy the inner authentication request to the "example.org" domain. Such cross-domain authentication is highly problematic, and there are few good reasons to allow it.
さらに悪いことに、「example.com」の設定ミスは、内部認証要求を「example.org」ドメインにプロキシする可能性があることを意味します。このようなクロスドメイン認証は非常に問題が多く、許可する正当な理由はほとんどありません。
It is therefore RECOMMENDED that systems that permit anonymous "outer" identifiers require that the "inner" domain be the same as, or a subdomain of, the "outer" domain. An authentication request using disparate realms is a security violation, and the request SHOULD be rejected.
したがって、匿名の「外部」識別子を許可するシステムでは、「内部」ドメインが「外部」ドメインと同じか、またはそのサブドメインである必要があることをお勧めします。異なるレルムを使用した認証リクエストはセキュリティ違反であり、リクエストは拒否されるべきです（SHOULD）。
The situation gets worse when multiple protocols are involved. The TTLS protocol permits Microsoft CHAP (MS-CHAP) [RFC2433] to be carried inside of the TLS tunnel. MS-CHAP defines its own identifier, which is encapsulated inside of the MS-CHAP exchange. That identifier is not required to be any particular format, is not required to be in UTF-8, and, in practice, can be one of many unknown character sets. There is no way in practice to determine which character set was used for that identifier.
複数のプロトコルが関係する場合、状況はさらに悪化します。 TTLSプロトコルは、Microsoft CHAP（MS-CHAP）[RFC2433]がTLSトンネル内で伝送されることを許可します。 MS-CHAPは独自の識別子を定義し、MS-CHAP交換の内部にカプセル化されます。その識別子は特定の形式である必要はなく、UTF-8である必要もありません。実際には、多くの不明な文字セットの1つになる可能性があります。その識別子に使用された文字セットを特定する方法は実際にはありません。
The result is that the "outer" EAP Identity carried by TTLS is likely to not even share the same character set as the "inner" identifier used by MS-CHAP. The two identifiers are entirely independent and fundamentally incomparable.
その結果、TTLSによって伝送される「外部」のEAP IDは、MS-CHAPで使用される「内部」の識別子と同じ文字セットさえ共有しない可能性があります。 2つの識別子は完全に独立しており、基本的には比較できません。
Such a protocol design is NOT RECOMMENDED.
そのようなプロトコル設計は推奨されません。
In order to avoid creating any new administrative procedures, administration of the NAI realm namespace piggybacks on the administration of the DNS namespace.
新しい管理手順の作成を回避するために、NAIレルム名前空間の管理は、DNS名前空間の管理に便乗します。
NAI realm names are required to be unique, and the rights to use a given NAI realm for roaming purposes are obtained coincident with acquiring the rights to use a particular Fully Qualified Domain Name (FQDN). Those wishing to use an NAI realm name should first acquire the rights to use the corresponding FQDN. Administrators MUST NOT publicly use an NAI realm without first owning the corresponding FQDN. Private use of unowned NAI realms within an administrative domain is allowed, though it is RECOMMENDED that example names be used, such as "example.com".
NAIレルム名は一意である必要があり、ローミング目的で特定のNAIレルムを使用する権利は、特定の完全修飾ドメイン名（FQDN）を使用する権利の取得と同時に取得されます。 NAIレルム名を使用したい場合は、対応するFQDNを使用する権利を最初に取得する必要があります。管理者は、対応するFQDNを最初に所有しない限り、NAIレルムを公に使用してはなりません。 「example.com」などのサンプル名を使用することをお勧めしますが、管理ドメイン内の所有されていないNAIレルムの私的使用は許可されています。
Note that the use of an FQDN as the realm name does not require use of the DNS for location of the authentication server. While Diameter [RFC6733] supports the use of DNS for location of authentication servers, existing RADIUS implementations typically use proxy configuration files in order to locate authentication servers within a domain and perform authentication routing. The implementations described in [RFC2194] did not use DNS for location of the authentication server within a domain. Similarly, existing implementations have not found a need for dynamic routing protocols or propagation of global routing information. Note also that there is no requirement that the NAI represent a valid email address.
レルム名としてFQDNを使用する場合、認証サーバーの場所にDNSを使用する必要がないことに注意してください。 Diameter [RFC6733]は認証サーバーの場所のDNSの使用をサポートしていますが、既存のRADIUS実装は通常、ドメイン内の認証サーバーを見つけて認証ルーティングを実行するためにプロキシ構成ファイルを使用します。 [RFC2194]で説明されている実装は、ドメイン内の認証サーバーの場所にDNSを使用しませんでした。同様に、既存の実装では、動的ルーティングプロトコルやグローバルルーティング情報の伝播の必要性は発見されていません。また、NAIが有効な電子メールアドレスを表す必要はないことにも注意してください。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月、<http://www.rfc-editor.org/info/rfc3629>。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008, <http://www.rfc-editor.org/info/rfc5198>.
[RFC5198] Klensin、J.およびM. Padlipsky、「Unicode Format for Network Interchange」、RFC 5198、2008年3月、<http://www.rfc-editor.org/info/rfc5198>。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D.、Ed。、およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月、<http://www.rfc-editor.org/info/ rfc5234>。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>.
[RFC5890] Klensin、J。、「Internationalized Domain Names for Applications（IDNA）：Definitions and Document Framework」、RFC 5890、2010年8月、<http://www.rfc-editor.org/info/rfc5890>。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010, <http://www.rfc-editor.org/info/rfc5891>.
[RFC5891] Klensin、J。、「Internationalized Domain Names in Applications（IDNA）：Protocol」、RFC 5891、2010年8月、<http://www.rfc-editor.org/info/rfc5891>。
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", BCP 166, RFC 6365, September 2011, <http://www.rfc-editor.org/info/rfc6365>.
[RFC6365] Hoffman、P。およびJ. Klensin、「IETFの国際化で使用される用語」、BCP 166、RFC 6365、2011年9月、<http://www.rfc-editor.org/info/rfc6365>。
[RFC2194] Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, "Review of Roaming Implementations", RFC 2194, September 1997, <http://www.rfc-editor.org/info/rfc2194>.
[RFC2194] Aboba、B.、Lu、J.、Alsopp、J.、Ding、J。、およびW. Wang、「ローミング実装のレビュー」、RFC 2194、1997年9月、<http：//www.rfc- editor.org/info/rfc2194>。
[RFC2341] Valencia, A., Littlewood, M., and T. Kolar, "Cisco Layer Two Forwarding (Protocol) "L2F"", RFC 2341, May 1998, <http://www.rfc-editor.org/info/rfc2341>.
[RFC2341] Valencia、A.、Littlewood、M。、およびT. Kolar、「Cisco Layer Two Forwarding（Protocol） "L2F"」、RFC 2341、1998年5月、<http://www.rfc-editor.org/ info / rfc2341>。
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433, October 1998, <http://www.rfc-editor.org/info/rfc2433>.
[RFC2433] Zorn、G。およびS. Cobb、「Microsoft PPP CHAP Extensions」、RFC 2433、1998年10月、<http://www.rfc-editor.org/info/rfc2433>。
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999, <http://www.rfc-editor.org/info/rfc2637>.
[RFC2637] Hamzeh、K.、Pall、G.、Verthein、W.、Taarud、J.、Little、W.、G。Zorn、「Point-to-Point Tunneling Protocol（PPTP）」、RFC 2637、7月1999、<http://www.rfc-editor.org/info/rfc2637>。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999, <http://www.rfc-editor.org/info/rfc2661>.
[RFC2661]タウンズリー、W。、バレンシア、A。、ルーベンス、A。、ポール、G。、ゾーン、G。、およびB.パルター、「レイヤー2トンネリングプロトコル "L2TP"」、RFC 2661、1999年8月、< http://www.rfc-editor.org/info/rfc2661>。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, 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、2000年6月、<http：//www.rfc- editor.org/info/rfc2865>。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000, <http://www.rfc-editor.org/info/rfc2866>.
[RFC2866] Rigney、C。、「RADIUS Accounting」、RFC 2866、2000年6月、<http://www.rfc-editor.org/info/rfc2866>。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003, <http://www.rfc-editor.org/info/rfc3492>.
[RFC3492] Costello、A。、「Punycode：A Bootstring encoding for Unicode for Internationalized Domain Names in Applications（IDNA）」、RFC 3492、2003年3月、<http://www.rfc-editor.org/info/rfc3492> 。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003, <http://www.rfc-editor.org/info/rfc3579>.
[RFC3579] Aboba、B。およびP. Calhoun、「RADIUS（Remote Authentication Dial In User Service）Support For Extensible Authentication Protocol（EAP）」、RFC 3579、2003年9月、<http://www.rfc-editor.org / info / rfc3579>。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, 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、2004年6月、<http：/ /www.rfc-editor.org/info/rfc3748>。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005, <http://www.rfc-editor.org/info/rfc4282>.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J。、およびP. Eronen、「The Network Access Identifier」、RFC 4282、2005年12月、<http://www.rfc-editor.org/info / rfc4282>。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月、<http://www.rfc-editor.org/info/rfc4301>。
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008, <http://www.rfc-editor.org/info/rfc5281>.
[RFC5281] Funk、P。およびS. Blake-Wilson、「Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0（EAP-TTLSv0）」、RFC 5281、2008年8月、<http：//www.rfc-editor。 org / info / rfc5281>。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008, <http://www.rfc-editor.org/info/rfc5322>.
[RFC5322] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、2008年10月、<http://www.rfc-editor.org/info/rfc5322>。
[RFC5335] Yang, A., Ed., "Internationalized Email Headers", RFC 5335, September 2008, <http://www.rfc-editor.org/info/rfc5335>.
[RFC5335] Yang、A。、編、「Internationalized Email Headers」、RFC 5335、2008年9月、<http://www.rfc-editor.org/info/rfc5335>。
[RFC5729] Korhonen, J., Ed., Jones, M., Morand, L., and T. Tsou, "Clarifications on the Routing of Diameter Requests Based on the Username and the Realm", RFC 5729, December 2009, <http://www.rfc-editor.org/info/rfc5729>.
[RFC5729] Korhonen、J.、Ed。、Jones、M.、Morand、L。、およびT. Tsou、「ユーザー名とレルムに基づくDiameterリクエストのルーティングに関する説明」、RFC 5729、2009年12月、< http://www.rfc-editor.org/info/rfc5729>。
[RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on Encodings for Internationalized Domain Names", RFC 6055, February 2011, <http://www.rfc-editor.org/info/rfc6055>.
[RFC6055] Thaler、D.、Klensin、J。、およびS. Cheshire、「IAB Thoughts on Encodings for Internationalized Domain Names」、RFC 6055、2011年2月、<http://www.rfc-editor.org/info/ rfc6055>。
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, February 2012, <http://www.rfc-editor.org/info/rfc6532>.
[RFC6532] Yang、A.、Steele、S。、およびN. Freed、「Internationalized Email Headers」、RFC 6532、2012年2月、<http://www.rfc-editor.org/info/rfc6532>。
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, 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、October 2012、<http：//www.rfc- editor.org/info/rfc6733>。
[RFC6912] Sullivan, A., Thaler, D., Klensin, J., and O. Kolkman, "Principles for Unicode Code Point Inclusion in Labels in the DNS", RFC 6912, April 2013, <http://www.rfc-editor.org/info/rfc6912>.
[RFC6912] Sullivan、A.、Thaler、D.、Klensin、J。、およびO. Kolkman、「Principles for Unicode Code Point Inclusions in Labels in the DNS」、RFC 6912、2013年4月、<http：// www。 rfc-editor.org/info/rfc6912>。
[EDUROAM] "eduroam (EDUcation ROAMing)", <http://eduroam.org>.
[EDUROAM]「eduroam（EDUcation ROAMing）」、<http://eduroam.org>。
[3GPP] 3GPP, "Numbering, addressing and Identification", 3GPP TS 23.003, Release 12, July 2014, <ftp://ftp.3gpp.org/Specs/archive/23_series/23.003/>.
[3GPP] 3GPP、「番号付け、アドレス指定、および識別」、3GPP TS 23.003、リリース12、2014年7月、<ftp://ftp.3gpp.org/Specs/archive/23_series/23.003/>。
This document contains the following updates with respect to the previous NAI definition in RFC 4282 [RFC4282]:
このドキュメントには、RFC 4282 [RFC4282]での以前のNAI定義に関する次の更新が含まれています。
* The formal syntax in Section 2.1 has been updated to forbid non-UTF-8 characters (e.g., characters with the "high bit" set).
* セクション2.1の正式な構文は、UTF-8以外の文字（「ハイビット」が設定された文字など）を禁止するように更新されました。
* The formal syntax in Section 2.1 of [RFC4282] has been updated to allow UTF-8 in the "realm" portion of the NAI.
* [RFC4282]のセクション2.1の正式な構文は、NAIの「レルム」部分でUTF-8を許可するように更新されました。
* The formal syntax in Section 2.1 of [RFC4282] applied to the NAI after it was "internationalized" via the ToAscii function. The contents of the NAI before it was "internationalized" were left indeterminate. This document updates the formal syntax to define an internationalized form of the NAI and forbids the use of the ToAscii function for NAI "internationalization".
* [RFC4282]のセクション2.1の正式な構文は、ToAscii関数によって「国際化」された後にNAIに適用されました。 「国際化」される前のNAIの内容は不確定のままでした。このドキュメントは、NAIの国際化された形式を定義するために正式な構文を更新し、NAIの「国際化」のためのToAscii関数の使用を禁止します。
* The grammar for the user and realm portion is based on a combination of the "nai" defined in Section 2.1 of [RFC4282] and the "utf8-addr-spec" defined in Section 4.4 of [RFC5335].
* ユーザーとレルムの部分の文法は、[RFC4282]のセクション2.1で定義された「nai」と[RFC5335]のセクション4.4で定義された「utf8-addr-spec」の組み合わせに基づいています。
* All use of the ToAscii function has been moved to normal requirements on DNS implementations when realms are used as the basis for DNS lookups. This involves no changes to the existing DNS infrastructure.
* レルムがDNSルックアップの基礎として使用されている場合、ToAscii関数のすべての使用は、DNS実装の通常の要件に移動しました。これには、既存のDNSインフラストラクチャへの変更は含まれません。
* The discussions on internationalized character sets in Section 2.4 of [RFC4282] have been updated. The suggestion to use the ToAscii function for realm comparisons has been removed. No AAA system has implemented these suggestions, so this change should have no operational impact.
* [RFC4282]のセクション2.4の国際化文字セットに関するディスカッションが更新されました。レルム比較にToAscii関数を使用するという提案は削除されました。これらの提案を実装したAAAシステムはないため、この変更による運用上の影響はありません。
* The "Routing inside of AAA Systems" section is new in this document. The concept of a "local AAA routing table" is also new, although it accurately describes the functionality of widespread implementations.
* 「AAAシステム内のルーティング」セクションは、このドキュメントの新機能です。 「ローカルAAAルーティングテーブル」の概念も新しいものですが、広範な実装の機能を正確に説明しています。
* The "Compatibility with EMail Usernames" and "Compatibility with DNS" sections have been revised and updated. The Punycode transformation is suggested to be used only when a realm name is used for DNS lookups, and even then the function is only used by a resolving API on the local system, and even then it is recommended that only the home network perform this conversion.
* 「電子メールユーザー名との互換性」および「DNSとの互換性」セクションが改訂および更新されました。 Punycode変換は、レルム名がDNSルックアップに使用されている場合にのみ使用することをお勧めします。さらに、関数はローカルシステムの解決APIによってのみ使用され、さらにホームネットワークのみがこの変換を実行することが推奨されます。
* The "Realm Construction" section has been updated to note that editing of the NAI is NOT RECOMMENDED.
* 「レルムの構築」セクションが更新され、NAIの編集は推奨されないことに注意してください。
* The "Examples" section has been updated to remove the instance of the IDN being converted to ASCII. This behavior is now forbidden.
* 「例」セクションが更新され、ASCIIに変換されるIDNのインスタンスが削除されました。この動作は現在禁止されています。
Acknowledgments
謝辞
The initial text for this document was [RFC4282], which was then heavily edited. The original authors of [RFC4282] were Bernard Aboba, Mark A. Beadles, Jari Arkko, and Pasi Eronen.
このドキュメントの最初のテキストは[RFC4282]でしたが、その後大幅に編集されました。 [RFC4282]の原作者は、Bernard Aboba、Mark A. Beadles、Jari Arkko、Pasi Eronenでした。
Author's Address
著者のアドレス
Alan DeKok The FreeRADIUS Server Project
Alan DeKok FreeRADIUSサーバープロジェクト
EMail: aland@freeradius.org