[要約] RFC 2989は、ネットワークアクセスのためのAAAプロトコルの評価基準を提供する。その目的は、ネットワークアクセス制御におけるAAAプロトコルの選択と実装を支援することである。
Network Working Group B. Aboba, Microsoft
Request for Comments: 2989 P. Calhoun, S. Glass, Sun Microsystems, Inc.
Category: Informational T. Hiller, P. McCann, H. Shiino, P. Walsh, Lucent
G. Zorn, G. Dommety, Cisco Systems, Inc.
C. Perkins, B. Patil, Nokia Telecommunications
D. Mitton, S. Manning, Nortel Networks
M. Beadles, SmartPipes Inc.
X. Chen, Alcatel
S. Sivalingham, Ericsson Wireless Communications
A. Hameed, Fujitsu
M. Munson, GTE Wireless
S. Jacobs, GTE Laboratories
B. Lim, LG Information & Communications, Ltd.
B. Hirschman, Motorola
R. Hsu, Qualcomm, Inc.
H. Koo, Samsung Telecommunications America, Inc.
M. Lipford, Sprint PCS
E. Campbell, 3Com Corporation
Y. Xu, Watercove Networks
S. Baba, Toshiba America Research, Inc.
E. Jaques, Vodaphone Airtouch
November 2000
Criteria for Evaluating AAA Protocols for Network Access
ネットワークアクセスのためのAAAプロトコルを評価するための基準
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
This document represents a summary of Authentication, Authorization, Accounting (AAA) protocol requirements for network access. In creating this document, inputs were taken from documents produced by the Network Access Server Requirements Next Generation (NASREQ), Roaming Operations (ROAMOPS), and MOBILEIP working groups, as well as from TIA 45.6.
このドキュメントは、ネットワークアクセスの認証、承認、会計（AAA）プロトコル要件の概要を表しています。このドキュメントを作成する際、入力は、ネットワークアクセスサーバー要件（NASREQ）、ローミング操作（ROAMOPS）、およびMobileIPワーキンググループ、およびTIA 45.6から作成されたドキュメントから取得されました。
This document summarizes the requirements collected from those sources, separating requirements for authentication, authorization and accounting. Details on the requirements are available in the original documents.
このドキュメントは、これらのソースから収集された要件を要約し、認証、承認、会計の要件を分離します。要件の詳細は、元のドキュメントで入手できます。
This document represents a summary of AAA protocol requirements for network access. In creating this documents, inputs were taken from documents produced by the NASREQ [3], ROAMOPS [2], and MOBILEIP [5] working groups, as well as from TIA 45.6 [4]. This document summarizes the requirements collected from those sources, separating requirements for authentication, authorization and accounting. Details on the requirements are available in the original documents.
このドキュメントは、ネットワークアクセスのためのAAAプロトコル要件の概要を表しています。このドキュメントを作成する際に、NASREQ [3]、Roamops [2]、およびMobileIP [5]ワーキンググループ、およびTIA 45.6 [4]によって作成されたドキュメントから入力が取得されました。このドキュメントは、これらのソースから収集された要件を要約し、認証、承認、会計の要件を分離します。要件の詳細は、元のドキュメントで入手できます。
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [1].
このドキュメントでは、キーワードは「可能性があります」、「必要はない」、「オプション」、「推奨」、「は」、「はすか」、「必要はありません」は、[1]で説明されているように解釈されるべきではありません。
Please note that the requirements specified in this document are to be used in evaluating AAA protocol submissions. As such, the requirements language refers to capabilities of these protocols; the protocol documents will specify whether these features are required, recommended, or optional. For example, requiring that a protocol support confidentiality is NOT the same thing as requiring that all protocol traffic be encrypted.
このドキュメントで指定されている要件は、AAAプロトコルの提出の評価に使用されることに注意してください。そのため、要件言語とは、これらのプロトコルの機能を指します。プロトコルドキュメントは、これらの機能が必要な、推奨、またはオプションであるかどうかを指定します。たとえば、プロトコルをサポートすることを要求することは、すべてのプロトコルトラフィックを暗号化することを要求するのと同じものではありません。
A protocol submission is not compliant if it fails to satisfy one or more of the MUST or MUST NOT requirements for the capabilities that it implements. A protocol submission that satisfies all the MUST, MUST NOT, SHOULD and SHOULD NOT requirements for its capabilities is said to be "unconditionally compliant"; one that satisfies all the MUST and MUST NOT requirements but not all the SHOULD or SHOULD NOT requirements for its protocols is said to be "conditionally compliant."
プロトコルの提出は、それが実装する機能の要件の1つ以上を満たすことができない場合、準拠していません。すべてのマストを満たすプロトコルの提出は、その機能の要件が「無条件に準拠している」と言われています。すべての要件を満たす必要があり、必要ではないものは、そのプロトコルの要件がすべて「条件付きに準拠」していると言われている場合とそうでないすべての要件ではありません。
Accounting The act of collecting information on resource usage for the purpose of trend analysis, auditing, billing, or cost allocation.
トレンド分析、監査、請求、またはコスト配分を目的として、リソース使用に関する情報を収集する行為を説明します。
Administrative Domain An internet, or a collection of networks, computers, and databases under a common administration. Computer entities operating in a common administration may be assumed to share administratively created security associations.
管理ドメインインターネット、または共通の管理下でのネットワーク、コンピューター、およびデータベースのコレクション。共通の管理者で動作するコンピューターエンティティは、管理上作成されたセキュリティ協会を共有すると想定される場合があります。
Attendant A node designed to provide the service interface between a client and the local domain.
アテンダントクライアントとローカルドメイン間のサービスインターフェイスを提供するように設計されたノード。
Authentication The act of verifying a claimed identity, in the form of a pre-existing label from a mutually known name space, as the originator of a message (message authentication) or as the end-point of a channel (entity authentication).
認証は、相互に既知の名前空間から既存のラベルの形で、メッセージ（メッセージ認証）またはチャネルのエンドポイント（エンティティ認証）として、既知の名前空間から既存のラベルの形で検証する行為。
Authorization The act of determining if a particular right, such as access to some resource, can be granted to the presenter of a particular credential.
認可されたリソースへのアクセスなど、特定の権利が特定の資格情報の発表者に付与できるかどうかを判断する行為。
Billing The act of preparing an invoice.
請求書を準備する行為を請求する。
Broker A Broker is an entity that is in a different administrative domain from both the home AAA server and the local ISP, and which provides services, such as facilitating payments between the local ISP and home administrative entities. There are two different types of brokers; proxy and routing.
ブローカーAブローカーは、Home AAAサーバーとローカルISPの両方とは異なる管理領域にあるエンティティであり、ローカルISPとホーム管理エンティティ間の支払いを促進するなどのサービスを提供します。ブローカーには2つの異なるタイプがあります。プロキシとルーティング。
Client A node wishing to obtain service from an attendant within an administrative domain.
クライアント管理ドメイン内のアテンダントからサービスを取得したいノード。
End-to-End End-to-End is the security model that requires that security information be able to traverse, and be validated even when an AAA message is processed by intermediate nodes such as proxies, brokers, etc.
エンドツーエンドのエンドツーエンドは、セキュリティ情報がプロキシ、ブローカーなどの中間ノードによって処理されている場合でも、セキュリティ情報を通過できることを要求し、検証するセキュリティモデルです。
Foreign Domain An administrative domain, visited by a Mobile IP client, and containing the AAA infrastructure needed to carry out the necessary operations enabling Mobile IP registrations. From the point of view of the foreign agent, the foreign domain is the local domain.
外国ドメインモバイルIPクライアントが訪問し、モバイルIP登録を可能にする必要な操作を実行するために必要なAAAインフラストラクチャを含む管理ドメイン。外国のエージェントの観点から見ると、外国の領域はローカルドメインです。
Home Domain An administrative domain, containing the network whose prefix matches that of a mobile node's home address, and containing the AAA infrastructure needed to carry out the necessary operations enabling Mobile IP registrations. From the point of view of the home agent, the home domain is the local domain.
ホームドメインは、モバイルノードのホームアドレスのプレフィックスと一致するネットワークを含む管理ドメインと、モバイルIP登録を可能にする必要な操作を実行するために必要なAAAインフラストラクチャが含まれています。ホームエージェントの観点から見ると、ホームドメインはローカルドメインです。
Hop-by-hop Hop-by-hop is the security model that requires that each direct set of peers in a proxy network share a security association, and the security information does not traverse a AAA entity.
ホップバイホップホップバイホップは、プロキシネットワーク内の各直接ピアセットがセキュリティ協会を共有することを要求するセキュリティモデルであり、セキュリティ情報はAAAエンティティを通過しません。
Inter-domain Accounting Inter-domain accounting is the collection of information on resource usage of an entity within an administrative domain, for use within another administrative domain. In inter-domain accounting, accounting packets and session records will typically cross administrative boundaries.
ドメイン間会計は、ドメイン間会計であり、他の管理ドメイン内で使用するための管理ドメイン内のエンティティのリソース使用に関する情報の収集です。ドメイン間会計では、会計パケットとセッションレコードは通常、管理境界を越えます。
Intra-domain Accounting Intra-domain accounting is the collection of information on resource within an administrative domain, for use within that domain. In intra-domain accounting, accounting packets and session records typically do not cross administrative boundaries.
ドメイン内会計内部ドメイン会計は、そのドメイン内で使用するための管理ドメイン内のリソースに関する情報の収集です。ドメイン内の会計では、会計パケットとセッションレコードは通常、管理境界を越えません。
Local Domain An administrative domain containing the AAA infrastructure of immediate interest to a Mobile IP client when it is away from home.
ローカルドメイン自宅から離れているときに、モバイルIPクライアントが即座に関心を持つAAAインフラストラクチャを含む管理ドメイン。
Proxy A AAA proxy is an entity that acts as both a client and a server. When a request is received from a client, the proxy acts as a AAA server. When the same request needs to be forwarded to another AAA entity, the proxy acts as a AAA client.
プロキシAAAプロキシは、クライアントとサーバーの両方として機能するエンティティです。クライアントからリクエストが受信されると、プロキシはAAAサーバーとして機能します。同じ要求を別のAAAエンティティに転送する必要がある場合、プロキシはAAAクライアントとして機能します。
Local Proxy A Local Proxy is a AAA server that satisfies the definition of a Proxy, and exists within the same administrative domain as the network device (e.g., NAS) that issued the AAA request. Typically, a local proxy will enforce local policies prior to forwarding responses to the network devices, and are generally used to multiplex AAA messages from a large number of network devices.
ローカルプロキシローカルプロキシは、プロキシの定義を満たすAAAサーバーであり、AAAリクエストを発行したネットワークデバイス（例：NAS）と同じ管理ドメイン内に存在します。通常、ローカルプロキシは、ネットワークデバイスへの応答を転送する前にローカルポリシーを実施し、一般に多数のネットワークデバイスからのマルチプレックスAAAメッセージに使用されます。
Network Access Identifier The Network Access Identifier (NAI) is the userID 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. The NAI may not necessarily be the same as the user's e-mail address or the user-ID submitted in an application layer authentication.
ネットワークアクセス識別子ネットワークアクセス識別子（NAI）は、ネットワークアクセス認証中にクライアントが提出したユーザーIDです。ローミングでは、NAIの目的は、ユーザーを特定するだけでなく、認証要求のルーティングを支援することです。NAIは、ユーザーの電子メールアドレスや、アプリケーションレイヤー認証で提出されたユーザーIDと必ずしも同じではない場合があります。
Routing Broker A Routing Broker is a AAA entity that satisfies the definition of a Broker, but is NOT in the transmission path of AAA messages between the local ISP and the home domain's AAA servers. When a request is received by a Routing Broker, information is returned to the AAA requester that includes the information necessary for it to be able to contact the Home AAA server directly. Certain organizations providing Routing Broker services MAY also act as a Certificate Authority, allowing the Routing Broker to return the certificates necessary for the local ISP and the home AAA servers to communicate securely.
ルーティングブローカールーティングブローカーは、ブローカーの定義を満たすAAAエンティティですが、ローカルISPとホームドメインのAAAサーバーの間のAAAメッセージの送信パスにはありません。ルーティングブローカーがリクエストを受信すると、情報がAAA要求者に返送されます。これには、Home AAAサーバーに直接連絡できるために必要な情報が含まれます。ルーティングブローカーサービスを提供する特定の組織は、証明書当局としても機能し、ルーティングブローカーがローカルISPおよびHome AAAサーバーに必要な証明書を確実に通信できるようにすることができます。
Non-Proxy Broker A Routing Broker is occasionally referred to as a Non-Proxy Broker.
非プロキシブローカールーティングブローカーは、時折非プロキシブローカーと呼ばれます。
Proxy Broker A Proxy Broker is a AAA entity that satisfies the definition of a Broker, and acts as a Transparent Proxy by acting as the forwarding agent for all AAA messages between the local ISP and the home domain's AAA servers.
プロキシブローカープロキシブローカーは、ブローカーの定義を満たすAAAエンティティであり、ローカルISPとホームドメインのAAAサーバーの間のすべてのAAAメッセージの転送エージェントとして機能することにより、透明なプロキシとして機能します。
Real-time Accounting Real-time accounting involves the processing of information on resource usage within a defined time window. Time constraints are typically imposed in order to limit financial risk.
リアルタイム会計リアルタイム会計には、定義された時間枠内でのリソース使用に関する情報の処理が含まれます。通常、財務リスクを制限するために時間の制約が課されます。
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が提供する企業ネットワークアクセスサポートが含まれます。
Session record A session record represents a summary of the resource consumption of a user over the entire session. Accounting gateways creating the session record may do so by processing interim accounting events.
セッションレコードセッションレコードは、セッション全体にわたるユーザーのリソース消費の要約を表します。会計ゲートウェイセッションレコードを作成すると、暫定会計イベントを処理することでそうすることができます。
Transparent Proxy A Transparent Proxy is a AAA server that satisfies the definition of a Proxy, but does not enforce any local policies (meaning that it does not add, delete or modify attributes or modify information within messages it forwards).
透明プロキシ透明プロキシは、プロキシの定義を満たすが、ローカルポリシーを実施しないAAAサーバーです（つまり、メッセージ内のメッセージ内の属性を追加、削除、または変更しない、または変更することはありません）。
The AAA protocol evaluation criteria for network access are summarized below. For details on the requirements, please consult the documents referenced in the footnotes.
ネットワークアクセスのAAAプロトコル評価基準を以下に要約します。要件の詳細については、脚注で参照されている文書を参照してください。
These requirements apply to all aspects of AAA and thus are considered general requirements.
これらの要件は、AAAのすべての側面に適用されるため、一般的な要件と見なされます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| General | NASREQ | ROAMOPS | MOBILE |
| Reqts. | | | IP |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Scalability | M | M | M |
| a | 12 | 3 | 30 39 |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Fail-over | M | | M |
| b | 12 | | 31 |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Mutual auth | M | | M |
| AAA client/server | 16 | | 30 |
| c | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Transmission level | | M | S |
| security | | 6 | 31 39 |
| d | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Data object | M | M | M |
| Confidentiality | 26 | 6 | 40 |
| e | | | |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Data object | M | M | M |
| Integrity | 16 | 6 | 31 39 |
| f | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Certificate transport | M | | S/M |
| g | 42 | |31,33/46 |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Reliable AAA transport | M | | M |
| mechanism | 22 | | 31 32 |
| h | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Run Over IPv4 | M | M | M |
| | 11 | 1 | 33 |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Run Over IPv6 | M | | S |
| | 11 | 1 | 47 |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Support Proxy and | M | | M |
| Routing Brokers | 12 | | 31 39 |
| i | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Auditability | S | | |
| j | 25 | | |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Dual App and Transport | | O | M |
| Security not required | | 6 | 40 |
| k | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Ability to carry | M | | S |
| service-specific attr. | 43 | | 31 33 |
| l | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key M = MUST S = SHOULD O = MAY N = MUST NOT B = SHOULD NOT Clarifications
key m = s = o = o = may n = b = b = clarifations b = b = come muse
[a] The AAA protocol must be capable of supporting millions of users and tens of thousands of simultaneous requests. The AAA architecture and protocol MUST be capable of supporting tens of thousands of devices, AAA servers, proxies and brokers.
[a] AAAプロトコルは、何百万人ものユーザーと数万の同時リクエストをサポートできる必要があります。AAAアーキテクチャとプロトコルは、何万ものデバイス、AAAサーバー、プロキシ、ブローカーをサポートできる必要があります。
[b] In the event of failure to communicate with a given server, the protocol must provide a mechanism to change service to another backup or secondary server.
[b] 特定のサーバーと通信できない場合、プロトコルは、サービスを別のバックアップまたはセカンダリサーバーに変更するメカニズムを提供する必要があります。
[c] This requirement refers to the ability to support mutual authentication between the AAA client and server.
[c] この要件とは、AAAクライアントとサーバー間の相互認証をサポートする機能を指します。
[d] The AAA protocol requires authentication, integrity protection and confidentiality at the transmission layer. This security model is also referred to as hop-by-hop security, whereas the security is established between two communicating peers. All of the security is removed when the AAA message is processed by a receiving AAA entity.
[d] AAAプロトコルでは、伝送層での認証、整合性の保護、および機密性が必要です。このセキュリティモデルはホップバイホップセキュリティとも呼ばれますが、セキュリティは2つの通信ピア間で確立されます。AAAメッセージが受信AAAエンティティによって処理されると、すべてのセキュリティが削除されます。
[e] The AAA protocol requires confidentiality at the object level, where an object consists of one or more attributes. Object level confidentiality implies that only the target AAA entity for whom the data is ultimately destined may decrypt the data, regardless of the fact that the message may traverse one or more intermediate AAA entities (e.g., proxies, brokers).
[e] AAAプロトコルには、オブジェクトが1つ以上の属性で構成されているオブジェクトレベルでの機密性が必要です。オブジェクトレベルの機密性は、メッセージが最終的に運命づけられているターゲットAAAエンティティのみが、メッセージが1つ以上の中間AAAエンティティ（プロキシ、ブローカーなど）を通過する可能性があるという事実に関係なく、データを解読する可能性があることを意味します。
[f] The AAA protocol requires authentication and integrity protection at the object level, which consists of one or more attributes. Object level authentication must be persistent across one or more intermediate AAA entity (e.g., proxy, broker, etc), meaning that any AAA entity in a proxy chain may verify the authentication. This implies that data that is covered by object level security CANNOT be modified by intermediate servers.
[f] AAAプロトコルには、1つ以上の属性で構成されるオブジェクトレベルでの認証と整合性保護が必要です。オブジェクトレベルの認証は、1つ以上の中間AAAエンティティ（プロキシ、ブローカーなど）にわたって永続的でなければなりません。つまり、プロキシチェーン内のAAAエンティティは認証を検証することができます。これは、オブジェクトレベルのセキュリティでカバーされているデータを中間サーバーで変更できないことを意味します。
[g] The AAA protocol MUST be capable of transporting certificates. This requirement is intended as an optimization, in lieu of requiring that an out-of-band protocol be used to fetch certificates.
[g] AAAプロトコルは、証明書を輸送できる必要があります。この要件は、証明書を取得するために帯域外プロトコルを使用することを要求する代わりに、最適化として意図されています。
[h] This requirement refers to resilience against packet loss, including:
[h] この要件とは、以下を含むパケット損失に対する回復力を指します。
1. Hop-by-hop retransmission and fail-over so that reliability does not solely depend on single hop transport retransmission.
1. 信頼性が単一ホップトランスポートの再送信にのみ依存しないように、ホップバイホップの再送信とフェールオーバー。
2. Control of the retransmission mechanism by the AAA application. 3. Acknowledgment by the transport that a message was delivered successfully, separate from message semantics or syntax evaluation. 5. Piggy-backing of acknowledgments in AAA messages. 6. Timely delivery of AAA responses.
2. AAAアプリケーションによる再送信メカニズムの制御。3.メッセージセマンティクスまたは構文評価とは別に、メッセージが正常に配信されたという輸送による承認。5. AAAメッセージの謝辞の貯金箱。6. AAA応答のタイムリーな配信。
[i] In the Mobile IP AAA architecture, brokers can be in the forwarding path, in which case they act as transparent proxies (proxy brokers). Alternatively, it is also possible to conceive of brokers operating as certifying authorities outside of the forwarding path (routing brokers).
[i] モバイルIP AAAアーキテクチャでは、ブローカーは転送パスにいる可能性があります。その場合、透明なプロキシ（プロキシブローカー）として機能します。あるいは、転送パス（ルーティングブローカー）以外の認定当局として運営されているブローカーを想像することも可能です。
[j] An auditable process is one in which it is possible to definitively determine what actions have been performed on AAA packets as they travel from the home AAA server to the network device and back.
[j] 監査可能なプロセスとは、Home AAAサーバーからネットワークデバイスへの移動際に、AAAパケットで実行されたアクションを明確に決定できるプロセスです。
[k] The AAA protocol MUST allow communication to be secured. However, the AAA protocol MUST also allow an underlying security service (e.g., IP Security) to be used. When the latter is used, the former MUST NOT be required.
[k] AAAプロトコルは、通信を保護する必要があります。ただし、AAAプロトコルは、基礎となるセキュリティサービス（IPセキュリティなど）を使用することも許可する必要があります。後者を使用する場合、前者を必要としないでください。
[l] The AAA protocol MUST be extensible by third parties (e.g., other IETF Working Groups), in order to define attributes that are specific to the service being defined. This requirement simply means that the AAA protocol MUST allow groups other than the AAA WG to define standard attributes.
[l] AAAプロトコルは、定義されているサービスに固有の属性を定義するために、第三者（例：他のIETFワーキンググループ）によって拡張可能でなければなりません。この要件は、AAAプロトコルがAAA WG以外のグループが標準属性を定義することを許可する必要があることを意味します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Authentication | NASREQ | ROAMOPS | MOBILE |
| Reqts. | | | IP |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| NAI Support | M | M | S/M |
| a | 9 | 2 |32,34,39/|
| | | | 40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| CHAP Support | M | M | |
| b | 10 | 3 | |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| EAP Support | M | S | |
| c | 10 | 3 | |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| PAP/Clear-Text Support | M | B | |
| d | 26 | 3 | |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Re-authentication | M | | S |
| on demand | 17 | | 33 |
| e | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Authorization Only | M | | |
| without Authentication | 9 | | |
| f | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key M = MUST S = SHOULD O = MAY N = MUST NOT B = SHOULD NOT Clarifications
key m = s = o = o = may n = b = b = clarifations b = b = come muse
[a] The AAA protocol MUST allow the use of Network Access Identifiers (NAI) [8] to identify users and/or devices.
[a] AAAプロトコルは、ユーザーやデバイスを識別するために、ネットワークアクセス識別子（NAI）[8]の使用を許可する必要があります。
[b] The AAA protocol MUST allow CHAP [20] authentication information to be transported. This is commonly used by Network Access Servers that request authentication of a PPP user.
[b] AAAプロトコルは、Chap [20]認証情報の輸送を許可する必要があります。これは、PPPユーザーの認証を要求するネットワークアクセスサーバーによって一般的に使用されます。
[c] The AAA protocol MUST allow for Extensible Authentication Protocol (EAP) [14] payload to be transported. Since some EAP authentication mechanisms require more than one round trip, the AAA protocol must allow for such authentication mechanisms to be used. The actual EAP authentication mechanism negotiated MUST be transparent to the AAA protocol. When EAP is used, authentication typically occurs between the user being authenticated and his/her home AAA server.
[c] AAAプロトコルは、拡張可能な認証プロトコル（EAP）[14]ペイロードを輸送する必要があります。一部のEAP認証メカニズムには複数の往復が必要なため、AAAプロトコルはそのような認証メカニズムを使用する必要があります。交渉された実際のEAP認証メカニズムは、AAAプロトコルに対して透過的でなければなりません。EAPを使用すると、ユーザーが認証されることと自宅のAAAサーバーの間で認証が発生します。
[d] While PAP is deprecated, it is still in widespread use for its original intended purpose, which is support of clear-text passwords. As a result, a AAA protocol will need to be able to securely transport clear-text passwords. This includes providing for confidentiality of clear-text passwords traveling over the wire, as well as protecting against disclosure of clear-text passwords to proxies in the forwarding path.
[d] PAPは非推奨ですが、クリアテキストパスワードのサポートである当初の意図された目的のために、まだ広く使用されています。その結果、AAAプロトコルは、クリアテキストパスワードを安全に輸送できる必要があります。これには、ワイヤーを走行するクリアテキストパスワードの機密性を提供すること、および転送パスでのプロキシへのクリアテキストパスワードの開示から保護することが含まれます。
[e] The AAA protocol MUST allow for a user to be re-authenticated on-demand. The protocol MUST allow for this event to be triggered by either the user, access device (AAA client), or the home or visited AAA server.
[e] AAAプロトコルは、ユーザーがオンデマンドを再認証することを許可する必要があります。このプロトコルは、このイベントをユーザー、アクセスデバイス（AAAクライアント）、または自宅またはAAAサーバーにアクセスすることによってトリガーされることを許可する必要があります。
[f] The AAA protocol MUST NOT require that credentials of the user be provided during authorization. The AAA protocol supports authorization by identification or assertion only.
[f] AAAプロトコルは、承認中にユーザーの資格情報を提供することを要求してはなりません。AAAプロトコルは、識別またはアサーションのみによる認可をサポートしています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Authorization | NASREQ | ROAMOPS | MOBILE |
| Reqts. | | | IP |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Static and Dynamic | | | |
| IPv4/6 Address Assign. | M | M | M |
| a | 11 | 5 | 32 36 |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| RADIUS gateway | M | M | M |
| capability | 44 | 3 | 45 |
| b | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Reject | M | M | M |
| capability | 12 | 4 | 39 |
| c | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Precludes layer 2 | N | N | |
| tunneling | 11 | 5 | |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Re-Authorization on | M | | S |
| demand | 18 | | 30 33 |
| d | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Support for Access Rules,| M | | |
| Restrictions, Filters | 11, 19 | | |
| e | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| State Reconciliation | M | | |
| f | 20 | | |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Unsolicited Disconnect | M | | |
| g | 18 | | |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key
M = MUST
S = SHOULD
O = MAY
N = MUST NOT
B = SHOULD NOT
Clarifications
説明
[a] The AAA protocol MUST allow a server to provide a static or dynamic address during the authorization phase of a user and/or device. The address assigned MUST be either of type IPv4 or IPv6. If both the client AND the server are aware of a pre-configured address, then it is considered static. Anything else is dynamic.
[a] AAAプロトコルは、ユーザーおよび/またはデバイスの承認フェーズ中にサーバーが静的または動的アドレスを提供できるようにする必要があります。割り当てられたアドレスは、タイプIPv4またはIPv6のいずれかである必要があります。クライアントとサーバーの両方が事前に構成されたアドレスを認識している場合、それは静的と見なされます。それ以外は動的です。
[b] This requirement refers to the ability of a new AAA protocol be sufficiently compatible with the large installed base of attributes for existing approaches (RADIUS), such that a server implementation could speak both protocols, or translate between them.
[b] この要件とは、サーバーの実装が両方のプロトコルを話すか、それらの間で翻訳することができるように、既存のアプローチ（RADIUS）の属性の大きなインストールベースと十分に互換性がある新しいAAAプロトコルの能力を指します。
[c] This requirement refers to the ability of a proxy broker to deny access without forwarding the access request to the AAA server, or to deny access after receiving an access accept from the AAA server.
[c] この要件とは、プロキシブローカーがAAAサーバーにアクセス要求を転送せずにアクセスを拒否する機能、またはAAAサーバーからアクセスを受信した後にアクセスを拒否する機能を指します。
[d] This requirement refers to the ability of the AAA client or server to trigger re-authorization, or to the ability of the server to send updated authorization information to the device, such as "stop service." Authorization can allow for a time period, then additional authorization can be sought to continue. A server can initially authorize a user to connect and receive services, but later decide the user is no longer allowed use of the service, for example after N minutes. Authorizations can have a time limit. Re-authorization does not necessarily imply re-authentication.
[d] この要件とは、AAAクライアントまたはサーバーが再承認をトリガーする機能、または「STOPサービス」などのデバイスに更新された認証情報を送信する機能を指します。承認により、期間は許可され、さらに継続するために追加の承認を求めることができます。サーバーは最初にユーザーにサービスを接続および受信することを許可できますが、後でユーザーがN分後にサービスの使用を許可されなくなったと判断します。承認には時間制限があります。再承認は、必ずしも再認可を意味するわけではありません。
[e] This requirement refers to the ability to of the protocol to describe access operational limitations and authorization restrictions to usage to the NAS which includes (but is not limited to):
[e] この要件とは、プロトコルの能力を指し、アクセス運用制限とNASに使用する（ただし、これらに限定されない）許可制限を説明する能力を指します。
1. Session expirations and Idle Timeouts 2. Packet filters 3. Static routes 4. QoS parameters
1. セッションの満了とアイドルタイムアウト2.パケットフィルター3.静的ルート4. QoSパラメーター
[f] This requirement refers to the ability of the NAS to use the AAA server to manage resource allocation state. This capability can assist with, but it is not synonymous with, simultaneous user login control, port usage limitations, or IP address pooling.
[f] この要件とは、NASがAAAサーバーを使用してリソース割り当て状態を管理する能力を指します。この機能は支援することができますが、同時のユーザーログイン制御、ポートの使用制限、またはIPアドレスプーリングと同義ではありません。
The design must provide for recovery from data loss due to a variety of faults, including NAS and AAA server reboots, and NAS/AAA server communication outages, and MUST be independent of the accounting stream. The granularity of the recovery of state information after an outage may be on the order of a fraction of a minute. In order to provide for state recovery, explicit session/resource status and update and disconnect messages will be required.
この設計は、NASやAAAサーバーの再起動、NAS/AAAサーバー通信停止など、さまざまな障害によるデータ損失からの回復を提供する必要があり、会計ストリームとは無関係でなければなりません。停止後の州情報の回復の粒度は、1分間の数分の1の順序である可能性があります。州の回復を提供するためには、明示的なセッション/リソースのステータスと更新および切断メッセージが必要になります。
Because of potential multi-domain issues, only systems that allocate or use a resource should track its state.
潜在的なマルチドメインの問題のため、リソースを割り当てるまたは使用するシステムのみがその状態を追跡する必要があります。
[g] This requirement refers to the ability of the AAA server to request the NAS to disconnect an active session for authorization policy reasons.
[g] この要件とは、AAAサーバーがNASに承認ポリシーの理由でアクティブなセッションを切断するように要求する能力を指します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Accounting | NASREQ | ROAMOPS | MOBILE |
| Reqts. | | | IP |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Real-time accounting | M | M | M |
| a | 14 | 7 | 31 |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Mandatory Compact | | M | |
| Encoding | | 7 | |
| b | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Accounting Record | | M | M |
| Extensibility | | 7 | 33 |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Batch Accounting | S | | |
| c | 21 | | |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Guaranteed Delivery | M | | M |
| d | 22 | | 31 |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Accounting Time Stamps | M | | M |
| e | 23 | | 40 |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Dynamic Accounting | M | | |
| f | 48 | | |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key
M = MUST
S = SHOULD
O = MAY
N = MUST NOT
B = SHOULD NOT
Clarifications
説明
[a] This requirement may be loosely defined as reporting synchronously with events. Typically the time window is on the order of seconds, not milliseconds.
[a] この要件は、イベントと同期して報告するものとして大まかに定義される場合があります。 通常、時間ウィンドウはミリ秒ではなく、秒程度にあります。
[b] The AAA protocol's Accounting data format MUST NOT be bloated, imposing a large overhead for one or more accounting data elements.
[b] AAAプロトコルの会計データ形式は肥大化してはならず、1つ以上の会計データ要素に大きなオーバーヘッドを課してはなりません。
[c] This requirement refers to the ability to buffer or store multiple accounting records, and send them together at some later time.
[c] この要件とは、複数の会計レコードをバッファリングまたは保存し、後でそれらを一緒に送信する機能を指します。
[d] This is an application layer acknowledgment. This is sent when the receiving server is willing to take responsibility for the message data.
[d] これはアプリケーションレイヤーの確認です。これは、受信サーバーがメッセージデータに対して責任を負うことをいとわないときに送信されます。
[e] This requirement refers to the ability to reflect the time of occurrence of events such as log-on, logoff, authentication, authorization and interim accounting. It also implies the ability to provide for unambiguous time-stamps.
[e] この要件とは、ログオン、ログオフ、認証、承認、暫定会計などのイベントの発生時間を反映する能力を指します。また、明確なタイムスタンプを提供する能力を意味します。
[f] This requirement refers to the ability to account for dynamic authentication and authorization. To support this, there can be multiple accounting records for a single session.
[f] この要件とは、動的な認証と承認を考慮する能力を指します。これをサポートするために、単一のセッションには複数の会計記録があります。
In addition to the above requirements, Mobile IP also has the following additional requirements:
上記の要件に加えて、モバイルIPには次の追加要件もあります。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Encoding of Mobile IP | | | M |
| registration messages | | | 33 |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Firewall friendly | | | M |
| a | | | 35 |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Allocation of local Home | | | S/M |
| agent | | | 37/41 |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key M = MUST S = SHOULD O = MAY N = MUST NOT B = SHOULD NOT
key m = s = o = may n = b = b = b = sufy che che che
Clarifications
説明
[a] A firewall friendly protocol is one which is designed to accommodate a firewall acting as a proxy. For example, this would permit a Home Agent AAA server situated behind a firewall to be reachable from the Internet for the purposes of providing AAA services to a Mobile IP Foreign Agent.
[a] ファイアウォールに優しいプロトコルは、プロキシとして機能するファイアウォールに対応するように設計されたプロトコルです。たとえば、これにより、モバイルIPの外国人エージェントにAAAサービスを提供する目的で、ファイアウォールの後ろに位置するホームエージェントAAAサーバーがインターネットからリーチできるようになります。
Notes
ノート
[1] Section 4.2.1 of [2]
[2] Section 4.2.2 of [2]. Also see [8].
[3] Section 4.2.3 of [2]. Also see [14].
[4] Section 4.2.4 of [2].
[5] Section 4.2.5 of [2].
[6] Section 4.2.6 of [2].
[7] Section 4.3 of [2].
[8] Section 6 of [3]. Also see [6].
[9] Section 8.2.2.2 of [3]. Also see [14].
[10] Section 8.2.2.1 of [3]. Also see [14].
[11] Section 8.3.2.2 of [3]. Also see [7].
[12] Section 8.1.1 of [3].
[13] Section 8.1.4.4 of [3].
[14] Section 8.4.1.2 of [3].
[15] Section 8.4.2 of [3].
[16] Section 8.1.3 of [3].
[17] Section 8.2.1.2 of [3].
[18] Section 8.3.1.1 of [3].
[19] Section 8.3.2.1 of [3]. Also see [7].
[20] Section 8.3.2.3 of [3]. Also see [6], [7].
[21] Section 8.4.1.3 of [3].
[22] Section 8.4.1.1 of [3].
[23] Section 8.4.1.4 of [3].
[24] Section 8.4.3.1 of [3].
[25] Section 8.4.3.2 of [3].
[26] Section 8.2.3.1 of [3].
[27] Section 8.3.3.1 of [3].
[28] Section 8.1.4.1 of [3].
[29] Refer [15]
[30] Section 3 of [5]
[31] Section 3.1 of [5]
[32] Section 4 of [5]
[33] Section 5 of [5]
[34] Section 5.1 of [5]
[35] Section 5.2 of [5]
[36] Section 5.3 of [5]
[37] Section 5.4 of [5]
[38] Section 5.5 of [5]
[39] Section 6 of [5]
[40] Section 5.1 of [4]
[41] Section 5.2.2 of [4]
[42] Section 8.2.2.2 of [3]
[43] Section 8.1.2.3 of [3]
[44] Section 8.1.2.2 of [3]
[45] Section 5.4 of [4]
[46] Section 7 of [4]
[47] Section 8 of [5]
[48] Section 8.4.1.5 of [3]
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999.
[2] Aboba、B。およびG. Zorn、「ローミングプロトコルを評価するための基準」、RFC 2477、1999年1月。
[3] Beadles, M. and D. Mitton, "Criteria for Evaluating Network Access Server Protocols", Work in Progress.
[3] Beadles、M。およびD. Mitton、「ネットワークアクセスサーバープロトコルを評価するための基準」は、進行中の作業です。
[4] Hiller, T., et al., "Cdma2000 Wireless Data Requirements for AAA", Work in Progress.
[4] Hiller、T.、et al。、「AAAのCDMA2000ワイヤレスデータ要件」、作業進行中。
[5] Glass, S., Hiller, T., Jacobs, S. and C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements", RFC 2977, October 2000.
[5] Glass、S.、Hiller、T.、Jacobs、S.およびC. Perkins、「モバイルIP認証、承認、および会計要件」、RFC 2977、2000年10月。
[6] Mitton, D., Beadles, M., "Network Access Server Requirements Next Generation (NASREQNG) NAS Model", RFC 2881, July 2000.
[6] Mitton、D.、Beadles、M。、「ネットワークアクセスサーバー要件（NasReqng）NASモデル」、RFC 2881、2000年7月。
[7] Mitton, D., "Network Access Server Requirements: Extended RADIUS Practices", RFC 2882, July 2000.
[7] Mitton、D。、「ネットワークアクセスサーバー要件：拡張RADIUSプラクティス」、RFC 2882、2000年7月。
[8] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[8] Aboba、B。およびM. Beadles、「ネットワークアクセス識別子」、RFC 2486、1999年1月。
[9] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[9] Rigney、C.、Willens、S.、Rubens、A。and W. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[10] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[10] Rigney、C。、「Radius Accounting」、RFC 2866、2000年6月。
[11] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[11] シンプソン、W。、編集者、「ポイントツーポイントプロトコル（PPP）」、STD 51、RFC 1661、1994年7月。
[12] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[12] Sklower、K.、Lloyd、B.、McGregor、G.、Carr、D。、およびT. Coradetti、「The PPP Multilink Protocol（MP）」、RFC 1990、1996年8月。
[13] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January 1994.
[13] シンプソン、W。、編集者、「PPP LCP拡張機能」、RFC 1570、1994年1月。
[14] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[14] Blunk、L。およびJ. Vollbrecht、「PPP拡張可能な認証プロトコル（EAP）」、RFC 2284、1998年3月。
[15] Solomon, J. and S. Glass, "Mobile-IPv4 Configuration Option for PPP IPCP", RFC 2290, Feb 1998
[15] Solomon、J。and S. Glass、「PPP IPCPのモバイルIPV4構成オプション」、RFC 2290、1998年2月
[16] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.
[16] Calhoun、P。およびC. Perkins、「IPv4のモバイルIPネットワークアクセス識別子拡張機能」、RFC 2794、2000年3月。
[17] Perkins, C., "IP Mobility Support", RFC 2002, Oct 1996.
[17] Perkins、C。、「IP Mobility Support」、RFC 2002、1996年10月。
[18] Johnson, D. and C. Perkins, "Mobility Support in IPv6", Work in Progress.
[18] Johnson、D。およびC. Perkins、「IPv6のモビリティサポート」、進行中の作業。
[19] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[19] Aboba、B。およびJ. Vollbrecht、「ローミングにおけるプロキシチェーンと政策実装」、RFC 2607、1999年6月。
[20] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[20] シンプソン、W。、「PPPチャレンジハンドシェイク認証プロトコル（CHAP）」、RFC 1994、1996年8月。
This document, being a requirements document, does not have any security concerns. The security requirements on protocols to be evaluated using this document are described in the referenced documents.
このドキュメントは、要件文書であるため、セキュリティの懸念はありません。このドキュメントを使用して評価されるプロトコルのセキュリティ要件は、参照されたドキュメントで説明されています。
This memo does not create any new number spaces for IANA administration.
このメモは、IANA管理のための新しい数字スペースを作成しません。
Thanks to the members of the Mobile IP, AAA, and NASREQ working groups who have discussed and commented on these requirements. We would also like to thank the members of the AAA evaluation team, Mike St. Johns, Barney Wolf, Mark Stevens, David Nelson, Dave Mitton, Basavaraj Patil and Stuart Barkley for their thorough review of this document.
モバイルIPのメンバー、AAA、およびこれらの要件について議論しコメントしてくれたNASREQのワーキンググループに感謝します。また、AAA評価チームのメンバーであるマイクセントジョンズ、バーニーウルフ、マークスティーブンス、デビッドネルソン、デイブミットン、バサヴァラジパティル、スチュアートバークレーにこの文書を徹底的にレビューしてくれたことにも感謝します。
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond、WA 98052
Phone: +1 425-936-6605
Fax: +1 425-936-7329
EMail: bernarda@microsoft.com
Pat R. Calhoun Network and Security Research Center, Sun Labs Sun Microsystems, Inc. 15 Network Circle Menlo Park, CA 94025
PAT R. Calhoun Network and Security Research Center、Sun Labs Sun Microsystems、Inc。15 Network Circle Menlo Park、CA 94025
Phone: +1 650-786-7733 EMail: pcalhoun@eng.sun.com Steven M. Glass Sun Microsystems 1 Network Drive Burlington, MA 01845
電話：1 650-786-7733メール：pcalhoun@eng.sun.com Steven M. Glass Sun Microsystems 1 Network Drive Burlington、MA 01845
Phone: +1 781-442-0504
Fax: +1 781-442-1677
EMail: steven.glass@sun.com
Tom Hiller Wireless Data Standards & Architectures Lucent Technologies 263 Shuman Drive Room 1HP2F-218 Naperville, IL 60563
トムヒラーワイヤレスデータ標準とアーキテクチャルーテクノロジー263シューマンドライブルーム1HP2F-218イリノイ州ナーパービル60563
Phone: +1 630-976-7673
EMail: tom.hiller@lucent.com
Peter J. McCann Lucent Technologies Rm 2Z-305 263 Shuman Blvd Naperville, IL 60566
Peter J. McCann Lucent Technologies RM 2Z-305 263 Shuman Blvd Naperville、IL 60566
Phone: +1 630-713 9359
EMail: mccap@lucent.com
Hajime Shiino Lucent Technologies Japan Ltd. 25 Mori Bldg. 1-4-30 Roppongi, Minato-ku Tokyo Japan
Hajime Shiino Lucent Technologies Japan Ltd. 25 Mori Bldg。1-4-30 Roppongi、Minato-Ku Tokyo Japan
Phone: +81-3-5561-3695
EMail: hshiino@lucent.com
Glen Zorn Cisco Systems, Inc. 500 108th Avenue N.E., Suite 500 Bellevue, WA 98004
Glen Zorn Cisco Systems、Inc。500 108th Avenue N.E.、Suite 500 Bellevue、WA 98004
Phone: +1 425-468-0955 EMail: gwz@cisco.com Gopal Dommety IOS Network Protocols Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706
電話：1 425-468-0955メール：gwz@cisco.com
Phone: +1 408-525-1404
Fax: +1 408-526-4952
EMail: gdommety@cisco.com
Charles E. Perkins Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, CA
チャールズE.パーキンスコミュニケーションシステムラボノキアリサーチセンター313フェアチャイルドドライブマウンテンビュー、カリフォルニア
Phone: +1 650-625-2986
Fax: +1-650-625-2502
EMail: charliep@iprg.nokia.com
Basavaraj Patil Nokia Networks 6000 Connection Dr. Irving, TX 75039
Basavaraj Patil Nokia Networks 6000 Connection Dr. Irving、TX 75039
Phone: +1 972-894-6709
Fax: +1 972-894-5349
EMail: Basavaraj.Patil@nokia.com
David Mitton Nortel Networks 880 Technology Park Drive Billerica, MA 01821
David Mitton Nortel Networks 880 Technology Park Drive Billerica、MA 01821
Phone: +1 978-288-4570
EMail: dmitton@nortelnetworks.com
Serge Manning Nortel Networks 2201 Lakeside Blvd Richardson, TX 75082-4399
セルジュマニングノーテルネットワーク2201 Lakeside Blvd Richardson、TX 75082-4399
Phone: +1 972-684-7277 EMail: smanning@nortelnetworks.com Mark Anthony Beadles SmartPipes, Inc. 565 Metro Place South Suite 300 Dublin, OH 43017
電話：1 972-684-7277メール：smanning@nortelnetworks.com Mark Anthony Beadles SmartPipes、Inc。565 Metro Place South Suite 300 Dublin、OH 43017
Phone: +1 614-923-5657
EMail: mbeadles@smartpipes.com
Pat Walsh Lucent Technologies 263 Shuman Blvd. 1F-545 Naperville, IL
Pat Walsh Lucent Technologies 263 Shuman Blvd.1F-545イリノイ州ネーパービル
Phone: +1 630-713-5063
EMail: walshp@lucent.com
Xing Chen Alcatel USA 1000 Coit Road Plano, TX 75075
Xing Chen Alcatel USA 1000 Coit Road Plano、TX 75075
Phone: +1 972-519-4142
Fax: +1 972-519-3300
EMail: xing.chen@usa.alcatel.com
Sanjeevan Sivalingham Ericsson Wireless Communications Inc., Rm Q-356C 6455 Lusk Blvd San Diego, CA 92126
Sanjeevan Sivalingham Ericsson Wireless Communications Inc.、RM Q-356C 6455 Lusk Blvd San Diego、CA 92126
Phone: +1 858-332-5670
EMail: s.sivalingham@ericsson.com
Alan Hameed Fujitsu 2801 Telecom Parkway Richardson, TX 75082
アラン・ハメド・フジツ2801テキサス州リチャードソンテキサス75082テレコムパークウェイリチャードソン
Phone: +1 972-479-2089 Mark Munson GTE Wireless One GTE Place Alpharetta, GA 30004
電話：1 972-479-2089マークマンソンGTEワイヤレスワンGTEプレイスアルファレッタ、ジョージア州30004
Phone: +1 678-339-4439
EMail: mmunson@mobilnet.gte.com
Stuart Jacobs Secure Systems Department GTE Laboratories 40 Sylvan Road, Waltham, MA 02451-1128
Stuart Jacobs Secure Systems Department GTE Laboratories 40 Sylvan Road、Waltham、MA 02451-1128
Phone: +1 781-466-3076
Fax: +1 781-466-2838
EMail: sjacobs@gte.com
Byung-Keun Lim LG Electronics, Ltd. 533, Hogye-dong, Dongan-ku, Anyang-shi, Kyungki-do,431-080 Korea
Byung-Keun Lim LG Electronics、Ltd。533、Hogye-Dong、Dongan-Ku、Anyang-Shi、Kyungki-Do、431-080 Korea
Phone: +82-31-450-7199
Fax: +82-31-450-7050
EMail: bklim@lgic.co.kr
Brent Hirschman 1501 Shure Dr. Arlington Hieghts, IL 60006
Brent Hirschman 1501 Shure Dr. Arlington Heights、IL 60006
Phone: +1 847-632-1563
EMail: qa4053@email.mot.com
Raymond T. Hsu Qualcomm Inc. 6455 Lusk Blvd. San Diego, CA 92121
レイモンドT. HSU Qualcomm Inc. 6455 Lusk Blvd.サンディエゴ、CA 92121
Phone: +1 619-651-3623 EMail: rhsu@qualcomm.com Haeng S. Koo Samsung Telecommunications America, Inc. 1130 E. Arapaho Road Richardson, TX 75081
電話：1 619-651-3623メール：rhsu@qualcomm.com Haeng S. Koo Samsung Telecommunications America、Inc.1130 E. Arapaho Road Richardson、TX 75081
Phone: +1 972-761-7755
EMail: hskoo@sta.samsung.com
Mark A. Lipford Sprint PCS 8001 College Blvd.; Suite 210 Overland Park, KS 66210
Mark A. Lipford Sprint PCS 8001 College Blvd。;スイート210オーバーランドパーク、KS 66210
Phone: +1 913-664-8335
EMail: mlipfo01@sprintspectrum.com
Ed Campbell 3Com Corporation 1800 W. Central Rd. Mount Prospect, IL 60056
Ed Campbell 3com Corporation 1800 W. Central Rd。マウントプロスペクト、イリノイ州60056
Phone: +1 847-342-6769
EMail: ed_campbell@3com.com
Name: Yingchun Xu WaterCove Networks One Century Centre, Suite 550 1750 E. Golf Road Schaumburg, IL
名前：Yingchun Xu Watercove Networks One Century Center、Suite 550 1750 E. Golf Road Schaumburg、IL
Phone: +1 847-477-9280
EMail: yxu@watercove.com
Shinichi Baba Toshiba America Research, Inc. PO Box 136, Convent Station, NJ 07961-0136
Shinichi Baba Toshiba America Research、Inc。PO Box 136、Convent Station、NJ 07961-0136
Phone: +1 973-829-4795 EMail: sbaba@tari.toshiba.com Eric Jaques Vodafone AirTouch 2999 Oak Road, MS-750 Walnut Creek, CA 94596
電話：1 973-829-4795メール：sbaba@tari.toshiba.com Eric Jaques Vodafone AirTouch 2999 Oak Road、MS-750 Walnut Creek、CA 94596
Phone: +1 925-279-6142
EMail: ejaques@akamail.com
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、この基準を実践するために必要な技術をカバーする可能性のある著作権、特許、または特許出願、またはその他の独自の権利を注意深く招待するよう招待しています。情報をIETFエグゼクティブディレクターに宛ててください。
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
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.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。