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
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.
著作権（C）インターネット協会（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].
この文書に記載されている、キーワード "MAY"、「MUST、 "MUST NOT"、 "オプション"、 "推奨"、 "SHOULD"、および "the" はならない、[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."
それはMUSTの一つ以上を満たすために失敗したか、それが実装する機能のためにはならない要件場合は、プロトコルの提出は準拠していません。すべてのMUSTを満たすプロトコル提案は、およびその機能のための要件は、「無条件に準拠した」と言われてすべきでないてはなりません。すべてのMUSTを満たし、すべてのSHOULDまたはそのプロトコルのための要件があると言われてはならない要件はならずではない一つの「条件付きで準拠しています。」
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ブローカーは、ホーム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.
エンドツーエンドのエンドツーエンドのセキュリティ情報を横断することができることを必要とするセキュリティ・モデルであり、AAAメッセージは等プロキシ、ブローカーなどの中間ノードにより処理される場合でも検証します
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.
プロキシA 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.
ローカルプロキシAローカルプロキシは、プロキシの定義を満たす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.
ルーティングブローカーAのルーティングブローカーは、ブローカーの定義を満たすAAA実体ですが、地元のISPとホームドメインのAAAサーバの間でAAAメッセージの送信経路ではありません。要求がルーティングブローカによって受信されると、情報は、直接ホームAAAサーバに連絡できるようにするために必要な情報を含むAAAリクエスタに戻されます。ルーティングブローカーサービスを提供する特定の組織はまた、ルーティングBrokerが安全に通信するためにローカルISPのために必要な証明書とホームAAAサーバを戻すことができる、認証局として機能することができます。
Non-Proxy Broker A Routing Broker is occasionally referred to as a Non-Proxy Broker.
非プロキシ・ブローカAルーティングブローカは、時折、非プロキシ・ブローカと呼ばれます。
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.
プロキシブローカーAプロキシブローカーは、ブローカーの定義を満たし、そして地元のISPとホームドメインのAAAサーバ間のすべての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）のいずれかを使用する能力として定義することができます。ローミング機能が必要になる場合があります例例としては、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).
透過プロキシA透過プロキシは、プロキシの定義を満たす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
キーM = MUST S = SHOULD O = MAY N = Bてはならないが=べきではありません
Clarifications
明確化
[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つまたは複数の属性から成るオブジェクトレベルでの認証と完全性保護を必要とします。オブジェクト・レベルの認証は、プロキシチェーン内の任意の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.
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.
AAAアプリケーションによる再送機構の2コントロール。メッセージの意味または構文評価から別のメッセージが正常に配信された交通機関3謝辞、。 AAAメッセージで確認応答の5ピギーバッキング。 AAA応答の6タイムリーな配信。
[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]は、監査可能なプロセスは、決定的に彼らが戻ってネットワーク機器とのホーム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
キーM = MUST S = SHOULD O = MAY N = Bてはならないが=べきではありません
Clarifications
明確化
[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プロトコルは、[14]ペイロードを搬送する拡張認証プロトコル（EAP）を可能にしなければなりません。いくつかの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.
PAPは廃止されている間、[D]、それはクリアテキストのパスワードのサポートがあり、その本来の目的のために広く使用中です。その結果、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
キーM = MUST S = SHOULD O = MAY N = Bてはならないが=べきではありません
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クライアントまたはサーバの能力、又はようなデバイスに更新許可情報を送信するサーバの能力を意味する「ストップサービス」。認可は、その後、追加の許可を継続しようとすることができ、期間を可能にすることができます。サーバーは、最初に接続してサービスを受けるが、後でユーザーはもはや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
[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]この要件は、リソース割当状態を管理するAAAサーバを使用するNASの能力を指します。この機能は、を支援することができますが、それは、同時ユーザーのログイン制御、ポートの使用制限、または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.
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]この要件は、許可ポリシーの理由でアクティブなセッションを切断するNASを要求するAAAサーバの能力を指します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| 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
キーM = MUST S = SHOULD O = MAY N = Bてはならないが=べきではありません
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プロトコルの会計データの形式は、一つ以上の会計データ要素の大きなオーバーヘッドを課す、肥大化しているはずがありません。
[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
キーM = MUST S = SHOULD O = MAY N = Bてはならないが=べきではありません
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]ファイアウォールフレンドリープロトコルはプロキシとして動作ファイアウォールを収容するように設計されたものです。例えば、これは、ファイアウォールの背後に位置するホームエージェントAAAサーバは、モバイルIP外部エージェントに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].
[1] [2] [2] [2]のセクション4.2.2のセクション4.2.1。また、[8]を参照してください。 [3] [2]のセクション4.2.3。また、[14]を参照してください。 [4] [2]のセクション4.2.4。 [5] [2]のセクション4.2.5を。 [6] [2]のセクション4.2.6を。 [7] [2]のセクション4.3。 [8] [3]のセクション6。また、[6]を参照してください。 [9]〜[3]のセクション8.2.2.2を。また、[14]を参照してください。 [10]のセクション8.2.2.1 [3]。また、[14]を参照してください。 [11]のセクション8.3.2.2 [3]。また、[7]を参照してください。 [12] [3]のセクション8.1.1。 [13]のセクション8.1.4.4 [3]。 [14]のセクション8.4.1.2 [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]
[15]のセクション8.4.2 [3]。 [16]のセクション8.1.3 [3]。 [17]のセクション8.2.1.2 [3]。 [18]のセクション8.3.1.1 [3]。 [19]のセクション8.3.2.1 [3]。また、[7]を参照してください。 [20]のセクション8.3.2.3 [3]。また、[7]、[6]を参照。 [21]のセクション8.4.1.3 [3]。 [22]のセクション8.4.1.1 [3]。 [23]のセクション8.4.1.4 [3]。 [24]のセクション8.4.3.1 [3]。 [25]のセクション8.4.3.2 [3]。 [26]のセクション8.2.3.1 [3]。 [27]のセクション8.3.3.1 [3]。 [28]のセクション8.1.4.1 [3]。 [29]参照の[15] [30] [5] [31]セクション3.1のセクション3 [5] [32]のセクション4 [5] [33] [5] [34]セクション5.1のセクション5 [ 5] [35]セクション5.2 [5] [36] [5] [37] 5.4のセクション5.3 [5] [5] [39]第6の[38]セクション5.5 [5] [40] [4] [41]セクション5.2.2のセクション5.1 [4] [42] [3] [44]セクション8.1.2.2 [3] [43]セクション8.1.2.3のセクション8.2.2.2 [3] [45] 5.4 [4] [46]のセクション7 [4] [47] [5] [48]セクション8.4.1.5のセクション8 [3]
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999.
[2] Aboba、B.およびG.ゾルン、 "ローミングプロトコルを評価するための基準"、RFC 2477、1999年1月を。
[3] Beadles, M. and D. Mitton, "Criteria for Evaluating Network Access Server Protocols", Work in Progress.
[3] Beadles、M.とD.ミトン、進行中で働いて「ネットワークアクセスサーバーのプロトコルを評価するための基準」。
[4] Hiller, T., et al., "Cdma2000 Wireless Data Requirements for AAA", Work in Progress.
[4]ヒラー、T.、ら、 "AAAのためにCDMA2000ワイヤレスデータ要件"、ProgressのWork。
[5] Glass, S., Hiller, T., Jacobs, S. and C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements", RFC 2977, October 2000.
[5]ガラス、S.、ヒラー、T.、ジェイコブス、S.およびC.パーキンス、 "モバイルIP認証、認可、およびアカウンティング要件"、RFC 2977、2000年10月。
[6] Mitton, D., Beadles, M., "Network Access Server Requirements Next Generation (NASREQNG) NAS Model", RFC 2881, July 2000.
[6]ミトン、D.、Beadles、M.、 "ネットワークアクセスサーバー要件次世代（NASREQNG）NASモデル"、RFC 2881、2000年7月。
[7] Mitton, D., "Network Access Server Requirements: Extended RADIUS Practices", RFC 2882, July 2000.
[7]ミトン、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.、ウィレンス、S.、ルーベン、A.およびW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）においてリモート認証ダイヤル"。
[10] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[10] Rigney、C.、 "RADIUSアカウンティング"、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.、ロイド、B.、マクレガー、G.、カー、D.およびT. Coradetti、 "PPPマルチリンクプロトコル（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]ブルンク、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]ソロモン、J.及びS.ガラス、 "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]カルフーン、P.とC.パーキンス、 "IPv4のモバイルIPネットワークアクセス識別子拡張"、RFC 2794、2000年3月。
[17] Perkins, C., "IP Mobility Support", RFC 2002, Oct 1996.
[17]パーキンス、C.、 "IPモビリティサポート"、RFC 2002、1996年10月。
[18] Johnson, D. and C. Perkins, "Mobility Support in IPv6", Work in Progress.
[18]ジョンソン、D.とC.パーキンス、 "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ワーキンググループのメンバーに感謝します。我々はまた、このドキュメントの彼らの徹底的な見直しのためのマイク・セントジョンズ、バーニー・ウルフ、マーク・スティーブンス、デビッド・ネルソン、デイブミトン、BasavarajパティルとスチュアートバークリーAAA評価チームのメンバーに感謝したいと思います。
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052
Phone: +1 425-936-6605 Fax: +1 425-936-7329 EMail: bernarda@microsoft.com
電話：+1 425-936-6605ファックス：+1 425-936-7329電子メール：bernarda@microsoft.com
Pat R. Calhoun Network and Security Research Center, Sun Labs Sun Microsystems, Inc. 15 Network Circle Menlo Park, CA 94025
パットR.カルフーンネットワークとセキュリティ研究センター、日Labsのサン・マイクロシステムズ株式会社15ネットワークサークルメンロパーク、CA 94025
Phone: +1 650-786-7733 EMail: pcalhoun@eng.sun.com
電話：+1 650-786-7733電子メール：calhoun@eng.sub.com
Steven M. Glass Sun Microsystems 1 Network Drive Burlington, MA 01845
スティーブンM.ガラスSun Microsystemsの1ネットワークドライブバーリントン、MA 01845
Phone: +1 781-442-0504 Fax: +1 781-442-1677 EMail: steven.glass@sun.com
電話：+1 781-442-0504ファックス：+1 781-442-1677電子メール：steven.glass@sun.com
Tom Hiller Wireless Data Standards & Architectures Lucent Technologies 263 Shuman Drive Room 1HP2F-218 Naperville, IL 60563
トム・ヒラーワイヤレスデータ規格とアーキテクチャルーセント・テクノロジーズ263シューマンドライブルーム1HP2F-218ネーパーヴィル、IL 60563
Phone: +1 630-976-7673 EMail: tom.hiller@lucent.com
電話：+1 630-976-7673電子メール：tom.hiller@lucent.com
Peter J. McCann Lucent Technologies Rm 2Z-305 263 Shuman Blvd Naperville, IL 60566
ピーター・J.マッキャンルーセント・テクノロジーズRmの2Z-305 263シューマンブルバードネーパーヴィル、IL 60566
Phone: +1 630-713 9359 EMail: mccap@lucent.com
電話：+1 630から713 9359 Eメール：mccap@lucent.com
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
電話：+ 81-3-5561-3695 Eメール：hshiino@lucent.com
Glen Zorn Cisco Systems, Inc. 500 108th Avenue N.E., Suite 500 Bellevue, WA 98004
グレンツォルンシスコシステムズ社500第108アベニューN.E.、スイート500ワシントン州ベルビュー98004
Phone: +1 425-468-0955 EMail: gwz@cisco.com
電話：+1 425-468-0955電子メール：gwz@cisco.com
Gopal Dommety IOS Network Protocols Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706
ゴパルDommety IOSネットワークプロトコルシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134-1706
Phone: +1 408-525-1404 Fax: +1 408-526-4952 EMail: gdommety@cisco.com
電話：+1 408-525-1404ファックス：+1 408-526-4952電子メール：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
電話：+1 650-625-2986ファックス：+ 1-650-625-2502 Eメール：charliep@iprg.nokia.com
Basavaraj Patil Nokia Networks 6000 Connection Dr. Irving, TX 75039
Basavarajパティルノキア・ネットワーク6000の接続博士アーヴィング、TX 75039
Phone: +1 972-894-6709 Fax: +1 972-894-5349 EMail: Basavaraj.Patil@nokia.com
電話：+1 972-894-6709ファックス：+1 972-894-5349電子メール：Basavaraj.Patil@nokia.com
David Mitton Nortel Networks 880 Technology Park Drive Billerica, MA 01821
デヴィッド・ミトンNortel Networksの880テクノロジーパークドライブビレリカ、MA 01821
Phone: +1 978-288-4570 EMail: dmitton@nortelnetworks.com
電話：+1 978-288-4570電子メール：dmitton@nortelnetworks.com
Serge Manning Nortel Networks 2201 Lakeside Blvd Richardson, TX 75082-4399
セルジュ・マニングNortel Networksの2201レイクサイドブルバード・リチャードソン、テキサス州75082から4399
Phone: +1 972-684-7277 EMail: smanning@nortelnetworks.com
電話：+1 972-684-7277電子メール：smanning@nortelnetworks.com
Mark Anthony Beadles SmartPipes, Inc. 565 Metro Place South Suite 300 Dublin, OH 43017
マーク・アンソニーBeadles SmartPipes、Inc.の565メトロ置き南スイート300ダブリン、OH 43017
Phone: +1 614-923-5657 EMail: mbeadles@smartpipes.com
電話：+1 614-923-5657電子メール：mbeadles@smartpipes.com
Pat Walsh Lucent Technologies 263 Shuman Blvd. 1F-545 Naperville, IL
パット・ウォルシュルーセント・テクノロジーズ263シューマンブルバード1F-545ネーパーヴィル、IL
Phone: +1 630-713-5063 EMail: walshp@lucent.com
電話：+1 630-713-5063電子メール：walshp@lucent.com
Xing Chen Alcatel USA 1000 Coit Road Plano, TX 75075
興チェンアルカテルUSA 1000年コイトロードプラノ、TX 75075
Phone: +1 972-519-4142 Fax: +1 972-519-3300 EMail: xing.chen@usa.alcatel.com
電話：+1 972-519-4142ファックス：+1 972-519-3300電子メール：xing.chen@usa.alcatel.com
Sanjeevan Sivalingham Ericsson Wireless Communications Inc., Rm Q-356C 6455 Lusk Blvd San Diego, CA 92126
Sanjeevan Sivalinghamエリクソンワイヤレスコミュニケーションズ株式会社、RmのQ-356C 6455ラスクブルバードサンディエゴ、CA 92126
Phone: +1 858-332-5670 EMail: s.sivalingham@ericsson.com
電話：+1 858-332-5670電子メール：s.sivalingham@ericsson.com
Alan Hameed Fujitsu 2801 Telecom Parkway Richardson, TX 75082
アラン・ハミード富士通2801テレコムパークウェイ・リチャードソン、TX 75082
Phone: +1 972-479-2089
電話：+1 972-479-2089
Mark Munson GTE Wireless One GTE Place Alpharetta, GA 30004
マーク・マンソンGTEワイヤレスワンGTE場所アルファレッタ、GA 30004
Phone: +1 678-339-4439 EMail: mmunson@mobilnet.gte.com
電話：+1 678-339-4439電子メール：mmunson@mobilnet.gte.com
Stuart Jacobs Secure Systems Department GTE Laboratories 40 Sylvan Road, Waltham, MA 02451-1128
スチュアート・ジェイコブスセキュアシステム部GTE研究所40シルバンロード、ウォルサム、マサチューセッツ州02451から1128
Phone: +1 781-466-3076 Fax: +1 781-466-2838 EMail: sjacobs@gte.com
電話：+1 781-466-3076ファックス：+1 781-466-2838電子メール：sjacobs@gte.com
Byung-Keun Lim LG Electronics, Ltd. 533, Hogye-dong, Dongan-ku, Anyang-shi, Kyungki-do,431-080 Korea
ビョングンリムLG電子、（株）533、Hogye洞、東安区、安養市、京畿-DO、431から080韓国
Phone: +82-31-450-7199 Fax: +82-31-450-7050 EMail: bklim@lgic.co.kr
電話：+ 82-31-450-7199ファックス：+ 82-31-450-7050 Eメール：bklim@lgic.co.kr
Brent Hirschman 1501 Shure Dr. Arlington Hieghts, IL 60006
ブレントハーシュマン1501 Shureの博士アーリントンハイツ、IL 60006
Phone: +1 847-632-1563 EMail: qa4053@email.mot.com
電話：+1 847-632-1563電子メール：qa4053@email.mot.com
Raymond T. Hsu Qualcomm Inc. 6455 Lusk Blvd. San Diego, CA 92121
レイモンド・T.・スークアルコム社6455ラスクブルバードサンディエゴ、CA 92121
Phone: +1 619-651-3623 EMail: rhsu@qualcomm.com
電話：+1 619-651-3623電子メール：rhsu@qualcomm.com
Haeng S. Koo Samsung Telecommunications America, Inc. 1130 E. Arapaho Road Richardson, TX 75081
Haeng S.クーサムスン通信アメリカ、Inc.の1130 E.アラパホー・ロード・リチャードソン、TX 75081
Phone: +1 972-761-7755 EMail: hskoo@sta.samsung.com
電話：+1 972-761-7755電子メール：hskoo@sta.samsung.com
Mark A. Lipford Sprint PCS 8001 College Blvd.; Suite 210 Overland Park, KS 66210
マーク・A. LipfordスプリントPCS 8001カレッジ・ブルバード;スイート210オーバーランドパーク、カンザス州66210
Phone: +1 913-664-8335 EMail: mlipfo01@sprintspectrum.com
電話：+1 913-664-8335電子メール：mlipfo01@sprintspectrum.com
Ed Campbell 3Com Corporation 1800 W. Central Rd. Mount Prospect, IL 60056
エド・キャンベルの3Com社1800 W.中央Rdを。マウントプロスペクト、IL 60056
Phone: +1 847-342-6769 EMail: ed_campbell@3com.com
電話：+1 847-342-6769電子メール：ed_campbell@3com.com
Name: Yingchun Xu WaterCove Networks One Century Centre, Suite 550 1750 E. Golf Road Schaumburg, IL
名前：Yingchun徐WaterCoveネットワークの一つセンチュリーセンター、スイート550 1750 E.ゴルフロードショームバーグ、IL
Phone: +1 847-477-9280 EMail: yxu@watercove.com
電話：+1 847-477-9280電子メール：yxu@watercove.com
Shinichi Baba Toshiba America Research, Inc. PO Box 136, Convent Station, NJ 07961-0136
真一馬場東芝アメリカリサーチ社の私書箱136、コンベントステーション、NJ 07961から0136
Phone: +1 973-829-4795 EMail: sbaba@tari.toshiba.com
電話：+1 973-829-4795電子メール：sbaba@tari.toshiba.com
Eric Jaques Vodafone AirTouch 2999 Oak Road, MS-750 Walnut Creek, CA 94596
エリック・ジャックボーダフォンAirTouch 2999オークロード、MS-750ウォルナットクリーク、CA 94596
Phone: +1 925-279-6142 EMail: ejaques@akamail.com
電話：+1 925-279-6142電子メール：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.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。