[要約] RFC 2486は、ネットワークアクセス識別子（NAI）に関する標準仕様であり、ユーザーの識別と認証を目的としています。NAIは、ネットワーク接続時にユーザーを一意に識別するための形式です。
Network Working Group B. Aboba
Request for Comments: 2486 Microsoft
Category: Standards Track M. Beadles
WorldCom Advanced Networks
January 1999
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 (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
In order to enhance the interoperability of roaming and tunneling services, it is desirable to have a standardized method for identifying users. This document proposes syntax for the Network Access Identifier (NAI), the userID submitted by the client during PPP authentication. It is expected that this will be of interest for support of roaming as well as tunneling. "Roaming capability" 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.
ローミングサービスとトンネリングサービスの相互運用性を強化するために、ユーザーを識別するための標準化された方法があることが望ましい。このドキュメントでは、ネットワークアクセス識別子（NAI）、PPP認証中にクライアントによって送信されたユーザーIDの構文を提案します。これは、ローミングおよびトンネリングのサポートにとって興味深いものになると予想されます。 「ローミング機能」は、正式な顧客とベンダーの関係を1つだけ維持しながら、複数のインターネットサービスプロバイダー（ISP）のいずれかを使用する機能として大まかに定義できます。ローミング機能が必要になる可能性がある例としては、ISP「コンフェデレーション」やISP提供の企業ネットワークアクセスサポートなどがあります。
Considerable interest has arisen recently in a set of features that fit within the general category of "roaming capability" for dialup Internet users. Interested parties have included:
最近、ダイヤルアップインターネットユーザーの「ローミング機能」の一般的なカテゴリに収まる一連の機能にかなりの関心が高まっています。利害関係者が含まれています：
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）。他の地域プロバイダーの取り組みと組み合わせて、より広いエリアにダイヤルアップサービスを提供することを目指しています。
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.
運用を他の国の1つ以上のISPの運用と組み合わせて、国のグループまたは大陸でより包括的なダイヤルアップサービスを提供することを希望する国内ISP。
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 Virtual Private Network (VPN), enabled by tunneling protocols such as PPTP, L2F, L2TP, and IPSEC tunnel mode.
従業員にグローバルなダイヤルアップサービスの包括的なパッケージを提供することを望む企業。これらのサービスには、PPTP、L2F、L2TP、IPSECトンネルモードなどのトンネリングプロトコルによって可能になる仮想プライベートネットワーク（VPN）経由の企業イントラネットへの安全なアクセスだけでなく、インターネットアクセスも含まれます。
In order to enhance the interoperability of roaming and tunneling services, it is desirable to have a standardized method for identifying users. This document proposes syntax for the Network Access Identifier (NAI). Examples of implementations that use the NAI, and descriptions of its semantics, can be found in [1].
ローミングサービスとトンネリングサービスの相互運用性を強化するために、ユーザーを識別するための標準化された方法があることが望ましい。このドキュメントでは、ネットワークアクセス識別子（NAI）の構文を提案します。 NAIを使用する実装の例とそのセマンティクスの説明は、[1]にあります。
This document frequently uses the following terms:
このドキュメントでは、次の用語を頻繁に使用しています。
Network Access Identifier The Network Access Identifier (NAI) is the userID submitted by the client during PPP 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 userID submitted in an application layer authentication.
ネットワークアクセス識別子ネットワークアクセス識別子（NAI）は、PPP認証中にクライアントによって送信されたユーザーIDです。ローミングでは、NAIの目的は、ユーザーを識別することと、認証要求のルーティングを支援することです。 NAIは、必ずしもユーザーの電子メールアドレスまたはアプリケーション層認証で送信されたユーザーIDと同じであるとは限らないことに注意してください。
Network Access Server The Network Access Server (NAS) is the device that clients dial 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).
ネットワークアクセスサーバーネットワークアクセスサーバー（NAS）は、クライアントがネットワークにアクセスするためにダイヤルするデバイスです。これはPPTP用語ではPPTPアクセスコンセントレータ（PAC）と呼ばれ、L2TP用語ではL2TPアクセスコンセントレータ（LAC）と呼ばれます。
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つを使用して、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トンネルモードなどのトンネリングプロトコルによって有効になるネットワークサービスです。トンネリングサービスの一例は、仮想プライベートネットワーク（VPN）を介した企業イントラネットへの安全なアクセスです。
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [9].
このドキュメントでは、キーワード「MAY」、「MUST、「MUST NOT」、「optional」、「recommended」、「SHOULD」、および「SHOULD NOT」は、[9]で説明されているように解釈されます。
As described in [1], there are now a number of services implementing dialup roaming, and the number of Internet Service Providers involved in roaming consortia is increasing rapidly.
[1]で説明されているように、ダイヤルアップローミングを実装するサービスは数多く存在し、ローミングコンソーシアムに関与するインターネットサービスプロバイダーの数は急速に増加しています。
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 PPP 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つは、ユーザーのホーム認証サーバーを識別できることです。ローミングで使用する場合、この機能は、ユーザーが最初のPPP認証でNASに送信したネットワークアクセス識別子（NAI）を介して実行されます。 NASは、トンネルエンドポイントを決定するために、新しいトンネルを開くプロセスの一部としてNAIを使用することも予想されます。
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 conforms to the BNF described in [5], the BNF of the realm portion allows the realm to begin with a digit, which is not permitted by the BNF described in [4]. This change was made to reflect current practice; although not permitted by the BNF described in [4], FQDNs such as 3com.com are commonly used, and accepted by current software.
このドキュメントで提案されているように、ネットワークアクセス識別子はuser @ realmという形式です。 NAIのユーザー部分は[5]で説明されているBNFに準拠していますが、レルム部分のBNFではレルムを数字で始めることができますが、これは[4]で説明されているBNFでは許可されていません。この変更は、現在の慣行を反映するために行われました。 [4]で説明されているBNFでは許可されていませんが、3com.comなどのFQDNが一般的に使用されており、現在のソフトウェアで受け入れられています。
Please note that NAS vendors may need to modify their devices so as to support the NAI as described in this document. Devices handling NAIs MUST support an NAI length of at least 72 octets.
このドキュメントで説明されているように、NASベンダーがNAIをサポートするようにデバイスを変更する必要がある場合があることに注意してください。 NAIを処理するデバイスは、少なくとも72オクテットのNAI長をサポートする必要があります。
The grammar for the NAI is given below, described in ABNF as documented in [7]. The grammar for the username is taken from [5], and the grammar for the realm is an updated version of [4].
[7]で文書化されているように、ABNFに記述されているNAIの文法を以下に示します。ユーザー名の文法は[5]から取得され、レルムの文法は[4]の更新バージョンです。
nai = username / ( username "@" realm ) username = dot-string
nai =ユーザー名/（ユーザー名 "@"レルム）ユーザー名=ドット文字列
realm = realm "." label
realm = realm "。"ラベル
label = let-dig * (ldh-str)
ラベル= let-dig *（ldh-str）
ldh-str = *( Alpha / Digit / "-" ) let-dig
dot-string = string / ( dot-string "." string )
ドット文字列=文字列/（ドット文字列 "。"文字列）
string = char / ( string char )
string = char /（string char）
char = c / ( "\" x )
char = c /（ "\" x）
let-dig = Alpha / Digit
Alpha = %x41-5A / %x61-7A ; A-Z / a-z
Digit = %x30-39 ;0-9
c = < any one of the 128 ASCII characters, but
not any special or SP >
x = %x00-7F
; all 127 ASCII characters, no exception
SP = %x20 ; Space character
special = "<" / ">" / "(" / ")" / "[" / "]" / "\" / "."
/ "," / ";" / ":" / "@" / %x22 / Ctl
Ctl = %x00-1F / %x7F
; the control characters (ASCII codes 0 through 31
; inclusive and 127)
Examples of valid Network Access Identifiers include:
有効なネットワークアクセス識別子の例は次のとおりです。
fred@3com.com
fred@foo-9.com
fred_smith@big-co.com
fred=?#$&*+-/^smith@bigco.com
fred@bigco.com
nancy@eng.bigu.edu
eng!nancy@bigu.edu
eng%nancy@bigu.edu
Examples of invalid Network Access Identifiers include:
無効なネットワークアクセス識別子の例は次のとおりです。
fred@foo
fred@foo_9.com
@howard.edu
fred@bigco.com@smallco.com
eng:nancy@bigu.edu
eng;nancy@bigu.edu
<nancy>@bigu.edu
[1] Aboba, B., Lu J., Alsop J., Ding J. and W. Wang, "Review of Roaming Implementations", RFC 2194, September 1997.
[1] Aboba、B.、Lu J.、Alsop J.、Ding J.、およびW. Wang、「ローミング実装のレビュー」、RFC 2194、1997年9月。
[2] Rigney C., Rubens A., Simpson W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[2] Rigney C.、Rubens A.、Simpson W.、およびS. Willens、「Remote Authentication Dial In User Service（RADIUS）」、RFC 2138、1997年4月。
[3] Rigney C., "RADIUS Accounting", RFC 2139, April 1997.
[3] Rigney C。、「RADIUS Accounting」、RFC 2139、1997年4月。
[4] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[4] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、1987年11月。
[5] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[5] Postel、J。、「Simple Mail Transfer Protocol」、STD 10、RFC 821、1982年8月。
[6] Gulbrandsen A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996.
[6] Gulbrandsen A.およびP. Vixie、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2052、1996年10月。
[7] Crocker, D. and P. Overrell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[7] Crocker、D.およびP. Overrell、「Augmented BNF for Syntax Specifications：ABNF」、RFC 2234、1997年11月。
[8] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[8] ケントS.およびR.アトキンソン、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[9] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
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 which transmit the user name in clear-text across the Internet, such as in RADIUS, described in [2] and [3]. In order to prevent snooping of the user name, protocols may use confidentiality services provided by IPSEC, described in [8].
NAIはユーザーの所属を明らかにするため、攻撃者がユーザー名スペースをさらに詳しく調査するのに役立つ場合があります。通常、この問題は、[2]と[3]で説明されているように、RADIUSのように、ユーザー名をクリアテキストでインターネット経由で送信するプロトコルで最も懸念されます。ユーザー名のスヌーピングを防ぐために、プロトコルは、[8]で説明されているIPSECによって提供される機密性サービスを使用する場合があります。
This document defines a new namespace that will need to be administered, namely the NAI realm namespace. In order to to avoid creating any new administrative procedures, administration of the NAI realm namespace will piggyback on the administration of the DNS namespace.
このドキュメントでは、管理が必要な新しい名前空間、つまりNAIレルムの名前空間を定義します。新しい管理手順の作成を回避するために、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. Using an NAI realm without ownership of the corresponding FQDN creates the possibility of conflict and therefore is to be discouraged.
NAIレルム名は一意である必要があり、ローミング目的で特定のNAIレルムを使用する権利は、特定の完全修飾ドメイン名（FQDN）を使用する権利の取得と同時に取得されます。 NAIレルム名を使用したい場合は、対応するFQDNを使用する権利を最初に取得する必要があります。対応するFQDNの所有権なしでNAIレルムを使用すると、競合が発生する可能性があるため、お勧めしません。
Note that the use of an FQDN as the realm name does not imply use of the DNS for location of the authentication server or for authentication routing. Since to date roaming has been implemented on a relatively small scale, existing implementations typically handle location of authentication servers within a domain and perform authentication routing based on local knowledge expressed in proxy configuration files. The implementations described in [1] have not found a need for use of DNS for location of the authentication server within a domain, although this can be accomplished via use of the DNS SRV record, described in [6]. 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を使用することを意味するわけではありません。今日までローミングは比較的小規模で実装されているため、既存の実装は通常、ドメイン内の認証サーバーの場所を処理し、プロキシ構成ファイルで表現されたローカル知識に基づいて認証ルーティングを実行します。 [1]で説明されている実装では、ドメイン内の認証サーバーの場所にDNSを使用する必要はありませんでしたが、[6]で説明されているDNS SRVレコードを使用して実現できます。同様に、既存の実装では、動的ルーティングプロトコル、またはグローバルルーティング情報の伝播の必要性は発見されていません。また、NAIが有効な電子メールアドレスを表す必要はないことにも注意してください。
Thanks to Glen Zorn of Microsoft for many useful discussions of this problem space.
この問題領域について多くの有益な議論をしてくれたマイクロソフトのグレンゾーンに感謝します。
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナードアボバマイクロソフトコーポレーションワンマイクロソフトウェイレドモンド、ワシントン州98052
Phone: 425-936-6605 EMail: bernarda@microsoft.com
電話：425-936-6605メール：bernarda@microsoft.com
Mark A. Beadles WorldCom Advanced Networks 5000 Britton Rd. Hilliard, OH 43026
Mark A. Beadles WorldCom Advanced Networks 5000 Britton Rd。ヒリアード、オハイオ州43026
Phone: 614-723-1941 EMail: mbeadles@wcom.net
電話：614-723-1941メール：mbeadles@wcom.net
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。