[要約] RFC 4282は、ネットワークアクセス識別子（NAI）に関する標準化された仕様であり、ネットワーク認証やアカウント識別のために使用されます。このRFCの目的は、NAIの構造と使用方法を定義し、ネットワークアクセスのセキュリティと効率を向上させることです。
Network Working Group B. Aboba
Request for Comments: 4282 Microsoft
Obsoletes: 2486 M. Beadles
Category: Standards Track ENDFORCE
J. Arkko
Ericsson
P. Eronen
Nokia
December 2005
The Network Access Identifier
ネットワークアクセス識別子
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
In order to provide roaming services, it is necessary to have a standardized method for identifying users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client during network authentication. "Roaming" may 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 where roaming capabilities might be required include ISP "confederations" and ISP-provided corporate network access support. This document is a revised version of RFC 2486, which originally defined NAIs. Enhancements include international character set and privacy support, as well as a number of corrections to the original RFC.
ローミングサービスを提供するには、ユーザーを識別するための標準化された方法を持つ必要があります。このドキュメントでは、ネットワーク認証中にクライアントが提出したユーザーIDであるネットワークアクセス識別子（NAI）の構文を定義します。「ローミング」は、複数のインターネットサービスプロバイダー（ISP）のいずれかを使用する能力としてゆるく定義される可能性がありますが、正式な顧客とベンダーの関係を1つだけと維持します。ローミング機能が必要な場所の例には、ISP「コンフェデレーション」とISPが提供する企業ネットワークアクセスサポートが含まれます。このドキュメントは、元々NAISを定義したRFC 2486の改訂版です。拡張機能には、国際的なキャラクターセットとプライバシーサポート、および元のRFCに対する多くの修正が含まれます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................3
1.2. Requirements Language ......................................4
1.3. Purpose ....................................................4
2. NAI Definition ..................................................4
2.1. Formal Syntax ..............................................4
2.2. NAI Length Considerations ..................................6
2.3. Support for Username Privacy ...............................6
2.4. International Character Sets ...............................7
2.5. Compatibility with E-Mail Usernames ........................8
2.6. Compatibility with DNS .....................................8
2.7. Realm Construction .........................................8
2.8. Examples ..................................................10
3. Security Considerations ........................................10
4. IANA Considerations ............................................11
5. References .....................................................11
5.1. Normative References ......................................11
5.2. Informative References ....................................12
Appendix A. Changes from RFC 2486 ................................14
Appendix B. Acknowledgements .....................................14
Considerable interest exists for a set of features that fit within the general category of "roaming capability" for network access, including dialup Internet users, Virtual Private Network (VPN) usage, wireless LAN authentication, and other applications. Interested parties have included the following:
ダイヤルアップインターネットユーザー、仮想プライベートネットワーク（VPN）使用、ワイヤレスLAN認証、その他のアプリケーションなど、ネットワークアクセスの「ローミング機能」の一般的なカテゴリ内に適合する一連の機能にかなりの関心があります。利害関係者には以下が含まれています。
o 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.
o 特定の州または州内で運営されている地域のインターネットサービスプロバイダー（ISP）は、他の地域プロバイダーの努力を組み合わせて、より広いエリアでダイヤルアップサービスを提供しようとしています。
o National ISPs wishing to combine their operations with those of one or more ISPs in another nation to offer more comprehensive dialup service in a group of countries or on a continent.
o 国立ISPは、他の国の1つまたは複数のISPの事業を組み合わせて、国または大陸のグループでより包括的なダイヤルアップサービスを提供したいと考えています。
o Wireless LAN hotspots providing service to one or more ISPs.
o 1つ以上のISPにサービスを提供するワイヤレスLANホットスポット。
o 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 [RFC2401].
o 従業員にグローバルベースでダイヤルアップサービスの包括的なパッケージを提供したい企業。これらのサービスには、VPNを介したインターネットアクセスと、ポイントツーポイントトンネルプロトコル（PPTP）[RFC2637]などのトンネリングプロトコルによって有効な企業イントラネットへの安全なアクセスが含まれます。 C2401]。
In order to enhance the interoperability of roaming 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]に記載されています。
This document is a revised version of RFC 2486 [RFC2486], which originally defined NAIs. Differences and enhancements compared to RFC 2486 are listed in Appendix A.
このドキュメントは、RFC 2486 [RFC2486]の改訂版であり、元々Naisを定義していました。RFC 2486と比較した違いと強化は、付録Aにリストされています。
This document frequently uses the following terms:
このドキュメントは、頻繁に次の用語を使用します。
Network Access Identifier
ネットワークアクセス識別子
The Network Access Identifier (NAI) is the user identity submitted by the client during network access authentication. In roaming, the purpose of the NAI is to identify the user as well as to assist in the routing of the authentication request. Please note that the NAI may not necessarily be the same as the user's e-mail address or the user identity submitted in an application layer authentication.
ネットワークアクセス識別子（NAI）は、ネットワークアクセス認証中にクライアントが提出したユーザーIDです。ローミングでは、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.
ローミング機能は、複数のインターネットサービスプロバイダー（ISP）のいずれかを使用する能力としてゆるく定義できますが、1つだけの正式な顧客とベンダーの関係を維持できます。ローミング機能が必要になる場合がある場合の例には、ISP「コンフェデレーション」とISPが提供する企業ネットワークアクセスサポートが含まれます。
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トンネルモードなどのトンネルプロトコルによって有効なネットワークサービスです。トンネルサービスの1つの例は、仮想プライベートネットワーク（VPN）を介して企業イントラネットへの安全なアクセスです。
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119].
このドキュメントでは、キーワードは「可能性があります」、「必要はない」、「オプション」、「推奨」、「は」、「必要はありません」、および「必要はありません」は、[RFC2119]に記載されているように解釈されるべきではありません。
As described in [RFC2194], there are a number of providers offering network access services, and the number of Internet Service Providers involved in roaming consortia is increasing rapidly.
[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）を介して達成されます。また、トンネルのエンドポイントを決定するために、Naseが新しいトンネルを開くプロセスの一部としてNAIを使用することも期待されています。
The grammar for the NAI is given below, described in Augmented Backus-Naur Form (ABNF) as documented in [RFC4234]. The grammar for the username is based on [RFC0821], and the grammar for the realm is an updated version of [RFC1035].
[RFC4234]に記載されているように、NAIの文法は以下に示されています。ユーザー名の文法は[RFC0821]に基づいており、領域の文法は[RFC1035]の更新バージョンです。
nai = username
nai =/ "@" realm
nai =/ username "@" realm
username = dot-string
dot-string = string
dot-string =/ dot-string "." string
string = char
string =/ string char
char = c
char =/ "\" x
c = %x21 ; '!' allowed
; '"' not allowed
c =/ %x23 ; '#' allowed
c =/ %x24 ; '$' allowed
c =/ %x25 ; '%' allowed
c =/ %x26 ; '&' allowed
c =/ %x27 ; ''' allowed
; '(', ')' not allowed
c =/ %x2A ; '*' allowed
c =/ %x2B ; '+' allowed
; ',' not allowed
c =/ %x2D ; '-' allowed
; '.' not allowed
c =/ %x2F ; '/' allowed
c =/ %x30-39 ; '0'-'9' allowed
; ';', ':', '<' not allowed
c =/ %x3D ; '=' allowed
; '>' not allowed
c =/ %x3F ; '?' allowed
; '@' not allowed
c =/ %x41-5a ; 'A'-'Z' allowed
; '[', '\', ']' not allowed
c =/ %x5E ; '^' allowed
c =/ %x5F ; '_' allowed
c =/ %x60 ; '`' allowed
c =/ %x61-7A ; 'a'-'z' allowed
c =/ %x7B ; '{' allowed
c =/ %x7C ; '|' allowed
c =/ %x7D ; '}' allowed
c =/ %x7E ; '~' allowed
; DEL not allowed
c =/ %x80-FF ; UTF-8-Octet allowed (not in RFC 2486)
; Where UTF-8-octet is any octet in the
; multi-octet UTF-8 representation of a
; unicode codepoint above %x7F.
; Note that c must also satisfy rules in
; Section 2.4, including, for instance,
; checking that no prohibited output is
; used (see also Section 2.3 of
; [RFC4013]).
x = %x00-FF ; all 128 ASCII characters, no exception;
; as well as all UTF-8-octets as defined
; above (this was not allowed in
; RFC 2486). Note that x must nevertheless
; again satisfy the Section 2.4 rules.
realm = 1*( label "." ) label
label = let-dig *(ldh-str)
ldh-str = *( alpha / digit / "-" ) let-dig
let-dig = alpha / digit
alpha = %x41-5A ; 'A'-'Z'
alpha =/ %x61-7A ; 'a'-'z'
digit = %x30-39 ; '0'-'9'
Devices handling NAIs MUST support an NAI length of at least 72 octets. Support for an NAI length of 253 octets is RECOMMENDED. However, the following implementation issues should be considered:
NAIを処理するデバイスは、少なくとも72オクテットのNAIの長さをサポートする必要があります。253オクテットのNAI長のサポートをお勧めします。ただし、次の実装の問題を考慮する必要があります。
o NAIs are often transported in the User-Name attribute of the Remote Authentication Dial-In User Service (RADIUS) protocol. Unfortunately, RFC 2865 [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.
o NAISは、多くの場合、リモート認証ダイヤルインユーザーサービス（RADIUS）プロトコルのユーザー名属性で輸送されます。残念ながら、セクション5.1のRFC 2865 [RFC2865]は、「少なくとも63オクテットを処理する能力が推奨される」と述べています。その結果、すべてのデバイスを介して63オクテットを超えてNAIを転送することはできない場合があります。さらに、単一のユーザー名属性のみがRADIUSメッセージに含まれ、最大属性の長さは253オクテットであるためです。半径は、253オクテットを超えるNAIの長さをサポートできません。
o NAIs can also be transported in the User-Name attribute of Diameter [RFC3588], which supports content lengths up to 2^24 - 9 octets. As a result, NAIs processed only by Diameter nodes can be very long. Unfortunately, an NAI transported over Diameter may eventually be translated to RADIUS, in which case the above limitations apply.
o NAISは、最大2^24-9オクテットのコンテンツの長さをサポートする直径[RFC3588]のユーザー名属性でも輸送できます。その結果、直径ノードのみで処理されるNAISは非常に長い場合があります。残念ながら、直径を越えて輸送されたNAIは最終的に半径に翻訳される可能性があります。その場合、上記の制限が適用されます。
Interpretation of the username part of the NAI depends on the realm in question. Therefore, the "username" part SHOULD be treated as opaque data when processed by nodes that are not a part of the authoritative domain (in the sense of Section 4) for that realm.
NAIのユーザー名部分の解釈は、問題の領域に依存します。したがって、「ユーザー名」部分は、その領域の権威あるドメイン（セクション4の意味で）の一部ではないノードで処理される場合、不透明なデータとして扱う必要があります。
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 it provides an unambiguous way to determine whether the username is intended to uniquely identify a single user.
状況によっては、NAISは、プライバシーを増やすために、より安全な方法でユーザー名部分を転送できる別の認証方法と一緒に使用されます。この場合、NAISは、ユーザー名パーツを省略することにより、短縮された形式で提供される場合があります。ユーザー名のパーツを省略すると、「匿名」などの固定ユーザー名パーツを使用することで推奨されます。これは、ユーザー名が単一のユーザーを一意に識別することを意図しているかどうかを判断する明確な方法を提供するためです。
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, the realm portion is typically required in order for the authentication exchange to be routed to the appropriate server.
ローミングのために、認証会話が進む前に、特定のNAIの適切なバックエンド認証サーバーを見つけることが通常必要です。その結果、認証交換が適切なサーバーにルーティングされるためには、通常、レルム部分が必要です。
This specification allows both international usernames and realms. International usernames are based on the use of Unicode characters, encoded as UTF-8 and processed with a certain algorithm to ensure a canonical representation. Internationalization of the realm portion of the NAI is based on "Internationalizing Domain Names in Applications (IDNA)" [RFC3490].
この仕様により、国際的なユーザー名とレルの両方が可能になります。国際的なユーザー名は、UTF-8としてエンコードされ、特定のアルゴリズムで処理され、標準表現を確保するために特定のアルゴリズムで処理されるUnicode文字の使用に基づいています。NAIの領域部分の国際化は、「アプリケーション（IDNA）の国際化ドメイン名」に基づいています[RFC3490]。
In order to ensure a canonical representation, characters of the username portion in an NAI MUST fulfill the ABNF in this specification as well as the requirements specified in [RFC4013]. These requirements consist of the following:
標準表現を確保するために、NAIのユーザー名部分の文字は、[RFC4013]で指定された要件と同様に、この仕様でABNFを満たす必要があります。これらの要件は次のもので構成されています。
o Mapping requirements, as specified in Section 2.1 of [RFC4013]. Mapping consists of mapping certain characters to others (such as SPACE) in order to increase the likelihood of correctly performed comparisons.
o [RFC4013]のセクション2.1で指定されているマッピング要件。マッピングは、特定の文字を他の文字（スペースなど）にマッピングすることで構成され、正しく実行された比較の可能性を高めます。
o Normalization requirements, as specified in Section 2.2 of [RFC4013], are also designed to assist in comparisons.
o [RFC4013]のセクション2.2で指定されている正規化要件は、比較を支援するように設計されています。
o Prohibited output. Certain characters are not permitted in correctly formed strings that follow Section 2.3 of [RFC4013]. Ensuring that NAIs conform to their ABNF is not sufficient; it is also necessary to ensure that they do not contain prohibited output.
o 禁止出力。特定の文字は、[RFC4013]のセクション2.3に従う正しく形成された文字列では許可されていません。NAISがABNFに準拠することで十分ではないことを確認してください。また、禁止された出力が含まれていないことを確認する必要があります。
o Bidirectional characters are handled as specified in Section 2.4 of [RFC4013].
o 双方向の文字は、[RFC4013]のセクション2.4で指定されているように処理されます。
o Unassigned code points are specified in Section 2.5 of [RFC4013]. The use of unassigned code points is prohibited.
o [RFC4013]のセクション2.5で、割り当てられていないコードポイントが指定されています。割り当てられていないコードポイントの使用は禁止されています。
The mapping, normalization, and bidirectional character processing MUST be performed by end systems that take international text as input. In a network access setting, such systems are typically the client and the Authentication, Authorization, and Accounting (AAA) server. NAIs are sent over the wire in their canonical form, and tasks such as normalization do not typically need to be performed by nodes that just pass NAIs around or receive them from the network. End systems MUST also perform checking for prohibited output and unassigned code points. Other systems MAY perform such checks, when they know that a particular data item is an NAI.
マッピング、正規化、および双方向の文字処理は、国際的なテキストを入力として取得する最終システムによって実行する必要があります。ネットワークアクセス設定では、そのようなシステムは通常、クライアントであり、認証、承認、および会計（AAA）サーバーです。NAISは標準的な形式でワイヤーを介して送信され、正規化などのタスクは、通常、NAISを通過したり、ネットワークから受け取ったりするノードによって実行する必要はありません。また、ENDシステムは、禁止されている出力と未割り当てのコードポイントのチェックを実行する必要があります。特定のデータ項目がNAIであることを知っている場合、他のシステムはそのようなチェックを実行する場合があります。
The realm name is an "IDN-unaware domain name slot" as defined in [RFC3490]. That is, it can contain only ASCII characters. An implementation MAY support Internationalized Domain Names (IDNs) using the ToASCII operation; see [RFC3490] for more information.
レルム名は、[RFC3490]で定義されている「IDN-UnaWareドメイン名スロット」です。つまり、ASCII文字のみを含めることができます。実装は、TOASCII操作を使用して国際化ドメイン名（IDN）をサポートする場合があります。詳細については、[RFC3490]を参照してください。
The responsibility for the conversion of internationalized domain names to ASCII is left for the end systems, such as network access clients and AAA servers. Similarly, we expect domain name comparisons, matching, resolution, and AAA routing to be performed on the ASCII versions of the internationalized domain names. This provides a canonical representation, ensures that intermediate systems such as AAA proxies do not need to perform translations, and can be expected to work through systems that are unaware of international character sets.
国際化されたドメイン名をASCIIに変換する責任は、ネットワークアクセスクライアントやAAAサーバーなどの最終システムに残されています。同様に、ドメイン名の比較、マッチング、解像度、およびAAAルーティングが、国際化されたドメイン名のASCIIバージョンで実行されると予想されます。これにより、標準的な表現が提供され、AAAプロキシなどの中間システムが翻訳を実行する必要がなく、国際的なキャラクターセットに気付いていないシステムを介して動作することが期待できます。
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 BNF described in [RFC0821], it has been extended for internationalization support as well as for purposes of Section 2.7, and is not necessarily compatible with the usernames used in e-mail. Note also that the internationalization requirements for NAIs and e-mail addresses are different, since the former need to be typed in only by the user himself and his own operator, not by others.
このドキュメントで提案されているように、ネットワークアクセス識別子はform user@realmです。NAIのユーザー部分は[RFC0821]に記載されているBNFに基づいていますが、国際化のサポートとセクション2.7の目的で拡張されており、電子メールで使用されるユーザー名と必ずしも互換性があるわけではないことに注意してください。また、NAISおよび電子メールアドレスの国際化要件は異なることに注意してください。前者は、他の人ではなく、ユーザー自身と彼自身のオペレーターによってのみ入力する必要があるためです。
The BNF of the realm portion allows the realm to begin with a digit, which is not permitted by the BNF described in [RFC1035]. This change was made to reflect current practice; although not permitted by the BNF described in [RFC1035], Fully Qualified Domain Names (FQDNs) such as 3com.com are commonly used and accepted by current software.
レルム部分のBNFは、[RFC1035]に記載されているBNFでは許可されていない数字で領域を始めることができます。この変更は、現在の慣行を反映するためになされました。[RFC1035]に記載されているBNFでは許可されていませんが、3Com.comなどの完全に適格なドメイン名（FQDNS）が一般的に使用され、現在のソフトウェアで受け入れられています。
NAIs are used, among other purposes, for routing AAA transactions to the user's home realm. Usually, the home realm appears in the 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 another mediating realm.
NAISは、他の目的の中でも、ユーザーのホームレルムへのAAAトランザクションをルーティングするために使用されます。通常、ホームレルムはNAIの領域に表示されますが、場合によっては別の領域を使用できます。これは、たとえば、ホームレルムが別の媒介領域を介してのみ到達できる場合に役立つ場合があります。
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.
このような使用法は、関係者が使用が許可されているという相互の合意を持たない限り、相互運用性を防ぐことができます。特に、NAISは、（a）指定された他の領域が利用可能であり、（b）他の領域がそのような使用法をサポートしているという明示的な知識を持っていない限り、ホーム領域とは異なる領域を使用してはなりません。送信者は、データベース、動的発見、またはここでは指定されていないその他の手段を介して、これらの条件の履行を決定する場合があります。他の領域の可用性はユーザーの場所または目的のアプリケーションに依存する可能性があるため、最初の状態はローミングの影響を受けることに注意してください。
The use of the home realm MUST be the default unless otherwise configured.
特に構成されていない限り、ホームレルムの使用はデフォルトでなければなりません。
Where these conditions are fulfilled, an NAI such as
これらの条件が満たされている場合、
user@homerealm.example.net
user@homerealm.example.net
MAY be represented as in
のように表現される場合があります
homerealm.example.net!user@otherrealm.example.net
homerealm.example.net！user@oterrealm.example.net
In this case, the part before the (non-escaped) '!' MUST be a realm name as defined in the ABNF in Section 2.1. This realm name is an "IDN-unaware domain name slot", just like the realm name after the "@" character; see Section 2.4 for details. When receiving such an NAI, the other realm MUST convert the format back to "user@homerealm.example.net" when passing the NAI forward, as well as applying appropriate AAA routing for the transaction.
この場合、（エスケープではない）「！」の前の部分セクション2.1のABNFで定義されているように、レルム名でなければなりません。このレルム名は、「@」文字の後のレルム名のように、「IDN-UnaWareドメイン名スロット」です。詳細については、セクション2.4を参照してください。そのようなNAIを受け取るとき、他の領域は、NAIを前方に通過するときにフォーマットを「user@homerealm.example.net」に戻し、トランザクションに適切なAAAルーティングを適用する必要があります。
The conversion process may apply also recursively. That is, after the conversion, the result may still have one or more '!' characters in the username. For instance, the NAI
変換プロセスも再帰的に適用される場合があります。つまり、変換後、結果にはまだ1つ以上の「！」ユーザー名の文字。たとえば、nai
other2.example.net!home.example.net!user@other1.example.net
would first be converted in other1.example.net to
最初にother1.example.netに変換されます
home.example.net!user@other2.example.net
home.example.net！user@other2.example.net
and then at other2.example.net finally to
そして、他の2.example.netで最終的に
user@homerealm.example.net
user@homerealm.example.net
Note that the syntax described in this section is optional and is not a part of the ABNF. The '!' character may appear in the username portion of an NAI for other purposes as well, and in those cases, the rules outlined here do not apply; the interpretation of the username is up to an agreement between the identified user and the realm given after the '@' character.
このセクションで説明する構文はオプションであり、ABNFの一部ではないことに注意してください。「！」文字は、他の目的のためにNAIのユーザー名部分にも表示される場合があり、そのような場合、ここで概説するルールは適用されません。ユーザー名の解釈は、識別されたユーザーと「@」文字の後に与えられた領域との間の合意に達します。
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
alice@xn--tmonesimerkki-bfbb.example.net
The last example uses an IDN converted into an ASCII representation.
最後の例では、ASCII表現に変換されたIDNを使用します。
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
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, described in [RFC2865] and [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 [RFC3588].
NAIはユーザーの家の所属を明らかにしているため、攻撃者がユーザー名スペースをさらに調査するのを支援する可能性があります。通常、この問題は、[RFC2865]および[RFC2866]で説明されているRADIUSなど、インターネット上のクリアテキストでユーザー名を送信するプロトコルで最も懸念されています。ユーザー名のスヌーピングを防ぐために、プロトコルは、IPSEC [RFC3579]によって保護された半径やTLS [RFC3588]によって保護された直径など、プロトコルがそれらを輸送するプロトコルによって提供される機密性サービスを使用する場合があります。
This specification adds the possibility of hiding the username part in the NAI, by omitting it. As discussed in Section 2.3, 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 mechanism have also been used with NAIs. For instance, some Extensible Authentication Protocol (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 privacy of the username is protected, even through intermediate nodes such as NASes.
この仕様は、省略して、NAIのユーザー名部分を隠す可能性を追加します。セクション2.3で説明したように、これは、NAISが安全な方法でユーザー名を転送できる個別の認証方法と一緒に使用される場合にのみ可能です。場合によっては、アプリケーション固有のプライバシーメカニズムもNAISで使用されています。たとえば、一部の拡張可能な認証プロトコル（EAP）メソッドは、NAI [RFC3748]のユーザー名部分にメソッド固有の仮名を適用します。これらのアプローチはどちらも領域を保護することはできませんが、輸送保護よりも彼らの利点は、naseなどの中間ノードを介して、ユーザー名のプライバシーが保護されていることです。
In order to avoid creating any new administrative procedures, administration of the NAI realm namespace piggybacks on the administration of the DNS namespace.
新しい管理手順の作成を避けるために、DNS名空間の管理に関するNai Realm NamespaceのPiggybackの管理。
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. Using an NAI realm without ownership of the corresponding FQDN creates the possibility of conflict and therefore is to be discouraged.
NAIレルム名は一意である必要があり、特定の完全に適格なドメイン名（FQDN）を使用する権利を獲得することと、ローミング目的で特定のNAIレルムを使用する権利が一致します。NAIレルム名を使用したい場合は、最初に対応するFQDNを使用する権利を取得する必要があります。対応するFQDNの所有権なしで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 [RFC3588] 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を使用する必要はないことに注意してください。直径[RFC3588]は認証サーバーの場所にDNSの使用をサポートしていますが、既存のRADIUS実装は通常、ドメイン内の認証サーバーを見つけて認証ルーティングを実行するためにプロキシ構成ファイルを使用します。[RFC2194]で説明されている実装では、ドメイン内の認証サーバーの位置にDNSを使用しませんでした。同様に、既存の実装では、動的なルーティングプロトコルやグローバルルーティング情報の伝播の必要性が見つかりませんでした。また、NAIが有効な電子メールアドレスを表しているという要件はないことに注意してください。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、Hoffman、P。、およびA. Costello、「アプリケーションの国際化ドメイン名（IDNA）」、RFC 3490、2003年3月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013] Zeilenga、K。、「SASLPREP：ユーザー名とパスワードのStringPrepプロファイル」、RFC 4013、2005年2月。
[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[RFC0821] Postel、J。、「Simple Mail Transfer Protocol」、STD 10、RFC 821、1982年8月。
[RFC2194] Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, "Review of Roaming Implementations", RFC 2194, September 1997.
[RFC2194] Aboba、B.、Lu、J.、Alsop、J.、Ding、J.、およびW. Wang、「Review of Roaming Exprentations」、RFC 2194、1997年9月。
[RFC2341] Valencia, A., Littlewood, M., and T. Kolar, "Cisco Layer Two Forwarding (Protocol) "L2F"", RFC 2341, May 1998.
[RFC2341] Valencia、A.、Littlewood、M。、およびT. Kolar、「Cisco Layer Two Forwarding（Protocol） "L2F" "、RFC 2341、1998年5月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[RFC2486] Aboba、B。およびM. Beadles、「ネットワークアクセス識別子」、RFC 2486、1999年1月。
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., and G. Zorn, "Point-to-Point Tunneling Protocol", RFC 2637, July 1999.
[RFC2637] Hamzeh、K.、Pall、G.、Verthein、W.、Taarud、J.、Little、W.、およびG. Zorn、「ポイントツーポイントトンネルプロトコル」、RFC 2637、1999年7月。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2661] Townsley、W.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、G。、およびB. Palter、 "Layer Two Tunneling Protocol" L2TP ""、RFC 2661、1999年8月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866] Rigney、C。、「Radius Accounting」、RFC 2866、2000年6月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579] Aboba、B。およびP. Calhoun、「RADIUS（リモート認証ダイヤルインユーザーサービス）拡張可能な認証プロトコル（EAP）のサポート」、RFC 3579、2003年9月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「直径ベースプロトコル」、RFC 3588、2003年9月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J.、およびH. Levkowetz、「拡張可能な認証プロトコル（EAP）」、RFC 3748、2004年6月。
[netsel-problem] Arkko, J. and B. Aboba, "Network Discovery and Selection Problem", Work in Progress, October 2005.
[Netsel-Problem] Arkko、J。およびB. Aboba、「ネットワークの発見と選択の問題」、2005年10月の作業。
This document contains the following updates with respect to the original NAI definition in RFC 2486 [RFC2486]:
このドキュメントには、RFC 2486 [RFC2486]の元のNAI定義に関する次の更新が含まれています。
o International character set support has been added for both usernames and realms. Note that this implies character codes 128 - 255 may be used in the username portion, which may be unacceptable to nodes that only support RFC 2486. Many devices already allow this behaviour, however.
o ユーザー名とレルの両方に国際的なキャラクターセットサポートが追加されました。これは、文字コード128-255がユーザー名部分で使用される可能性があることを意味することに注意してください。これは、RFC 2486のみをサポートするノードに受け入れられない場合があります。ただし、多くのデバイスはすでにこの動作を許可しています。
o Username privacy support has been added. Note that NAIs without a username (for privacy) may not be acceptable to RFC 2486-compliant nodes. Many devices already allow this behaviour, however.
o ユーザー名のプライバシーサポートが追加されました。ユーザー名のないNAIS（プライバシー用）は、RFC 2486準拠のノードには受け入れられない場合があることに注意してください。ただし、多くのデバイスはすでにこの動作を許可しています。
o A recommendation to support NAI length of at least 253 octets has been added, and compatibility considerations among NAI lengths in this specification and various AAA protocols are discussed. Note that long NAIs may not be acceptable to RFC 2486-compliant nodes.
o 少なくとも253個のオクテットのNAIの長さをサポートするための推奨事項が追加されており、この仕様とさまざまなAAAプロトコルのNAIの長さの互換性の考慮事項について説明します。長いNAIは、RFC 2486準拠のノードに受け入れられない場合があることに注意してください。
o The mediating network syntax and its implications have been fully described and not given only as an example. Note that this syntax is not intended to be a full solution to network discovery and selection needs as defined in [netsel-problem]. Rather, it is intended as a clarification of RFC 2486.
o 媒介ネットワークの構文とその意味は完全に説明されており、例としてのみ与えられていません。この構文は、[Netsel-Problem]で定義されているように、ネットワークの発見と選択のニーズに対する完全なソリューションではないことに注意してください。むしろ、RFC 2486の明確化として意図されています。
However, as discussed in Section 2.7, this specification requires that this syntax be applied only when there is explicit knowledge that the peer system supports such syntax.
ただし、セクション2.7で説明したように、この仕様では、ピアシステムがそのような構文をサポートするという明示的な知識がある場合にのみ、この構文を適用する必要があります。
o The realm BNF entry definition has been changed to avoid an error (infinite recursion) in the original specification.
o 元の仕様のエラー（無限再帰）を回避するために、レルムBNFエントリ定義が変更されました。
o Several clarifications and improvements have been incorporated into the ABNF specification for NAIs.
o NAISのABNF仕様にいくつかの説明と改善が組み込まれています。
Thanks to Glen Zorn for many useful discussions of this problem space, and to Farid Adrangi for suggesting the representation of mediating networks in NAIs. Jonathan Rosenberg reported the BNF error. Dale Worley suggested clarifications of the x and special BNF entries. Arne Norefors reported the length differences between RFC 2486 and RFC 2865. Paul Hoffman helped with the international character set issues. Kalle Tammela, Stefaan De Cnodder, Nagi Jonnala, Bert Wijnen, Blair Bullock, Yoshihiro Ohba, Ignacio Goyret, John Loughney, Henrik Levkowetz, Ted Hardie, Bill Fenner, Sam Hartman, and Richard Perlman provided many useful comments on this document. The ABNF validator at http://www.apps.ietf.org/abnf.html was used to verify the syntactic correctness of the ABNF in Section 2.1.
この問題空間についての多くの有用な議論をしてくれたGlen Zornに感謝し、NAISの媒介ネットワークの表現を提案してくれたFarid Adrangiに感謝します。Jonathan RosenbergはBNFエラーを報告しました。Dale Worleyは、Xと特別なBNFエントリの説明を提案しました。Arne Noreforsは、RFC 2486とRFC2865の長さの違いを報告しました。ポール・ホフマンは、国際的なキャラクターセットの問題を手伝いました。Kalle Tammela、Stefaan de Cnodder、Nagi Jonnala、Bert Wijnen、Blair Bullock、Yoshihiro Ohba、Ignacio Goyret、John Loughney、Henrik Levkowetz、Ted Hardie、Bill Fenner、Sam Hartman、およびRichard Perlmanがこの文書に多くの有用なコメントを提供しました。http://www.apps.ietf.org/abnf.htmlのABNFバリデーターを使用して、セクション2.1のABNFの構文正しさを検証しました。
Authors' Addresses
著者のアドレス
Bernard Aboba Microsoft One Microsoft Way Redmond, WA 98052 USA
バーナード・アボバ・マイクロソフト・ワン・マイクロソフト・ウェイ・レドモンド、ワシントン州98052 USA
EMail: bernarda@microsoft.com
Mark A. Beadles ENDFORCE 565 Metro Place South Suite 300 Dublin OH 43017 USA
マークA.ビードルエンドフォース565メトロプレイスサウススイート300ダブリンOH 43017 USA
EMail: mbeadles@endforce.com
Jari Arkko Ericsson Jorvas 02420 Finland
Jari Arkko Ericsson Jorvas 02420フィンランド
EMail: jari.arkko@ericsson.com
Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland
Pasi Eronen Nokia Research Center P.O.Box 407 Fin-00045 Nokia Group Finland
EMail: pasi.eronen@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供され、貢献者、インターネット社会とインターネットエンジニアリングタスクフォースが代表する、または後援する組織、またはインターネットエンジニアリングタスクフォースは、すべての保証を否認します。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用、またはそのような権利に基づくライセンスに基づくライセンスが利用可能である可能性がある範囲に関連すると主張される可能性のある他の権利の範囲に関してはありません。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果、http://ww.ietf.org/IPRでIETFオンラインIPRリポジトリから取得できます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。