Network Working Group M. Beadles
Request for Comments: 3169 SmartPipes, Inc.
Category: Informational D. Mitton
Nortel Networks
September 2001
Criteria for Evaluating Network Access Server Protocols
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 (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This document defines requirements for protocols used by Network Access Servers (NAS).
この文書では、ネットワークアクセスサーバー（NAS）で使用されるプロトコルのための要件を定義します。
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [KEYWORDS].
この文書に記載されている、キーワード "MAY"、「MUST、 "MUST NOT"、 "オプション"、 "推奨"、 "SHOULD"、および "the" はならない、[KEYWORDS]で説明されるように解釈されるべきです。
This document defines requirements for protocols used by Network Access Servers (NAS). Protocols used by NAS's may be divided into four spaces: Access protocols, Network protocols, AAA protocols, and Device Management protocols. The primary focus of this document is on AAA protocols.
この文書では、ネットワークアクセスサーバー（NAS）で使用されるプロトコルのための要件を定義します。アクセスプロトコル、ネットワークプロトコル、AAAプロトコル、およびデバイスの管理プロトコル：NAS年代によって使用されるプロトコルは、4つのスペースに分かれていてもよいです。このドキュメントの主な焦点は、AAAプロトコルにあります。
The reference model of a NAS used by this document, and the analysis of the functions of a NAS which led to the development of these requirements, may be found in [NAS-MODEL].
本文書で使用されるNASの参照モデル、およびこれらの要件の開発につながったNASの機能の分析、[NAS-MODEL]に見出すことができます。
There are three basic types of access protocols used by NAS's. First are the traditional telephony-based access protocols, which interface to the NAS via a modem or terminal adapter or similar device. These protocols typically support asynchronous or synchronous PPP [PPP]
NAS年代によって使用されるアクセス・プロトコルの3つの基本タイプがあります。最初の従来の電話ベースのアクセスプロトコル、モデムやターミナルアダプタまたは類似のデバイスを介してNASへのインタフェースです。これらのプロトコルは、典型的には、サポート非同期または同期PPP [PPP]
carried over a telephony protocol. Second are broadband pseudo-telephony access protocols, which are carried over xDSL or cable modems, for example. These protocols typically support an encapsulation method such as PPP over Ethernet [PPPOE]. Finally are the virtual access protocols used by NAS's that terminate tunnels. One example of this type of protocol is L2TP [L2TP].
電話プロトコルを介して搬送されます。第二の例のために、のxDSLまたはケーブルモデムを介して搬送される広帯域擬似テレフォニー・アクセス・プロトコルです。これらのプロトコルは、典型的に、イーサネット上のPPP [PPPOE]としてカプセル化方式をサポートしています。最後にトンネルを終端NAS年代によって使用される仮想アクセスプロトコルです。プロトコルのこのタイプの一例は、L2TP [L2TP]です。
It is a central assumption of the NAS model used here that a NAS accepts multiple point-to-point links via one of the above access protocols. Therefore, at a minimum, any NAS access protocol MUST be able to carry PPP. The exception to this requirement is for NAS's that support legacy text login methods such as telnet [TELNET], rlogin, or LAT. Only these access protocols are exempt from the requirement to support PPP.
これは、NASは、上記のアクセスプロトコルの1つを介して複数のポイントツーポイントリンクを受け入れ、ここで使用されたNASモデルの中心的な仮定です。このため、最低でも、任意のNASアクセスプロトコルは、PPPを運ぶことができなければなりません。この要件の例外は、そのようなtelnetの[TELNET]、rloginまたはLATなどのレガシーテキストのログイン方法をサポートするNAS用のためのものです。のみ、これらのアクセスプロトコルはPPPをサポートするための要件を免除されています。
The network protocols supported by a NAS depend entirely on the kind of network to which a NAS is providing access. This document does not impose any additional requirements on network protocols beyond the protocol specifications themselves. For example, if a NAS that serves a routed network includes internet routing functionality, then that NAS must adhere to [ROUTING-REQUIREMENTS], but there are no additional protocol requirements imposed by virtue of the device being a NAS.
NASがサポートするネットワーク・プロトコルは、NASのアクセスを提供されているネットワークの種類に完全に依存します。この文書では、プロトコル仕様そのものを越えたネットワークプロトコル上の任意の追加要件を課していません。たとえば、ルーティングされたネットワークを提供している場合、NASは、その後、NASは、[ルーティング要件]に準拠しなければならないことを、インターネットのルーティング機能を含むが、NASれるデバイスによって課される追加のプロトコルの要件は存在しません。
There are certain general characteristics that any AAA protocol used by NAS's must meet. Note that the transport requirements for authentication/authorization are not necessarily the same as those for accounting/auditing. An AAA protocol suite MAY use the same transport and protocol for both functions, but this is not strictly required.
NAS年代によって使用されるすべてのAAAプロトコルを満たしている必要があり、特定の一般的な特徴があります。認証/承認のための輸送要件は、必ずしも会計/監査のためのものと同じではないことに注意してください。 AAAプロトコルスイートには、両方の機能のために同じトランスポートとプロトコルを使用することができるが、これは必須ではありません。
The design of the AAA protocol MUST be transport independent. Existing infrastructures use UDP-based protocols [RADIUS], gateways to new protocols must be practical to encourage migration. The design MUST comply with congestion control recommendations in RFC 2914 [CONGEST].
AAAプロトコルの設計は、トランスポート独立していなければなりません。既存のインフラストラクチャは、[RADIUS] UDPベースのプロトコルを使用して、新しいプロトコルへのゲートウェイは、移行を奨励するのは実用的でなければなりません。デザインは、RFC 2914 [輻輳]における輻輳制御の勧告に従わなければなりません。
Very large scale NAS's that serve up to thousands of simultaneous sessions are now being deployed. And a single server system may service a large number of ports. This means that, in the extreme, there may be an almost constant exchange of many small packets between the NASes and the AAA server. An AAA protocol transport SHOULD support being optimized for a long-term exchange of small packets in a stream between a pair of hosts.
同時セッションの数千人にまで役立つ超大規模のNASのは、現在展開されています。そして、単一のサーバシステムは、多数のポートにサービスを提供することがあります。これは極端な場合、のNASとAAAサーバとの間の多数の小さなパケットのほぼ一定の交換があってもよい、ということを意味します。 AAAプロトコルトランスポートはホストのペア間の流れの小さなパケットの長期交換のために最適化されているサポートすべきです。
The protocol MUST be designed to support a large number of ports, clients, and concurrent sessions. Examples of poor design would include message identifiers which values are so small that queues and reception windows wrap under load, unique session identifier ranges that are so small that they wrap within the lifetime of potential long sessions, counter values that cannot accommodate reasonable current and future bandwidth usage, and computational processes with high overhead that must be performed frequently.
プロトコル、ポート、クライアント、および同時セッションの多数をサポートするように設計されなければなりません。貧しいデザインの例は、値がキューと受信ウィンドウは、負荷の下で、彼らは合理的な現在および将来の対応ができない可能性のある長いセッション、カウンタ値の有効期間内包むほど小さい一意のセッション識別子の範囲を包むほど小さいメッセージ識別子が含まれるであろう帯域幅の使用量、および頻繁に行われなければならない高いオーバーヘッドで演算処理。
In order to operationally support large loads, load balancing and fail-over to multiple AAA servers will be required. The AAA protocol MUST provide for NAS's to balance individual AAA requests between two or more AAA servers. The load balancing mechanism SHOULD be built in to the AAA protocol itself.
操作上、負荷分散を大きな負荷をサポートし、フェイルオーバーを複数のAAAサーバにするためには必要となります。 AAAプロトコルは、二つ以上のAAAサーバ間の個々のAAA要求のバランスを取るためにNASのために提供しなければなりません。ロード・バランシング・メカニズムは、AAAプロトコル自体に組み込まれるべきです。
The AAA protocol MUST be able to detect a failure of the transport protocol to deliver a message or messages within a known and controllable time period, so it can engage retransmission or server fail-over processes. The reliability and robustness of authentication requests MUST be predictable and configurable.
AAAプロトコルは、再送またはサーバフェイルオーバー処理を係合できるように、既知の制御可能な時間内にメッセージまたはメッセージを配信するトランスポートプロトコルの故障を検出することができなければなりません。認証要求の信頼性と堅牢性は予測可能で構成可能でなければなりません。
The AAA protocol design MUST NOT introduce a single point of failure during the AAA process. The AAA protocol MUST allow any sessions between a NAS and a given AAA server to fail-over to a secondary server without loss of state information. This fail-over mechanism SHOULD be built in to the AAA protocol itself.
AAAプロトコルの設計はAAAプロセスの間に単一障害点を導入してはなりません。 AAAプロトコルはNASと所定のAAAサーバとの間のセッションがフェイルオーバーするためにセカンダリサーバに状態情報の損失なしに許容しなければなりません。このフェイルオーバーメカニズムは、AAAプロトコル自体に組み込まれるべきです。
NAS's operated by one authority provide network access services for clients operated by another authority, to network destinations operated by yet another authority. This type of arrangement is of growing importance; for example, dial roaming is now a nearly ubiquitous service. Therefore, the AAA protocol MUST support AAA services that travel between multiple domains of authority. The AAA protocol MUST NOT use a model that assumes a single domain of authority.
1つの機関が運営するNAS年代は、さらに別の権限で動作するネットワークの宛先に、別の機関が運営するクライアントのネットワークアクセスサービスを提供しています。このタイプの構成は、重要性の高まりです。例えば、ダイヤルローミングは現在、ほぼユビキタスサービスです。したがって、AAAプロトコルは、権限の複数のドメイン間を移動するAAAサービスをサポートしなければなりません。 AAAプロトコルは、権限の単一のドメインを前提としたモデルを使用してはなりません。
The AAA protocol MUST NOT dictate particular business models for the relationship between the administrative domains. The AAA protocol MUST support proxy, and in addition SHOULD support other multi-domain relationships such as brokering and referral.
AAAプロトコルは、管理ドメイン間の関係のために、特定のビジネス・モデルを決定してはなりません。 AAAプロトコルはプロキシをサポートしなければなりません、そしてさらにそのような仲介や紹介などの他のマルチドメインの関係をサポートしなければなりません。
The AAA protocol MUST also meet the protocol requirements specified in [ROAMING-REQUIREMENTS].
AAAプロトコルはまた、[ローミング要件]で指定されたプロトコルの要件を満たさなければなりません。
Years of operational experience with AAA protocols and NAS's has proven that the Attribute-Value protocol model is an optimal representation of AAA data. The protocol SHOULD use an Attribute-Value representation for AAA data. This document will assume such a model. Even if the AAA protocol does not use this as an on-the-wire data representation, Attribute-Value can serve as abstraction for discussing AAA information.
AAAプロトコルとNASの持つ運用経験年数は、属性値のプロトコルモデルは、AAAデータの最適な表現であることを証明しました。プロトコルは、AAAのデータのための属性値表現を使用すべきです。この文書では、このようなモデルを仮定します。 AAAプロトコルは、オン・ザ・ワイヤデータ表現としてこれを使用しない場合でも、属性値は、AAA情報を議論するための抽象化として機能することができます。
Experience has also shown that attribute space tends to run out quickly. In order to provide room for expansion in the attribute space, the AAA protocol MUST support a minimum of 64K Attributes (16 bits), each with a minimum length of 64K (16 bits).
経験はまた、属性空間は、すぐに実行する傾向があることが示されています。属性空間の拡大のための余地を提供するために、AAAプロトコルは64Kの最小の長さ（16ビット）と64K属性（16ビット）、それぞれの最小値をサポートしなければなりません。
The AAA protocol MUST support simple attribute data types, including integer, enumeration, text string, IP address, and date/time. The AAA protocol MUST also provide some support for complex structured data types. Wherever IP addresses are carried within the AAA protocol, the protocol MUST support both IPv4 and IPv6 [IPV6] addresses. Wherever text information is carried within the AAA protocol, the protocol MUST comply with the IETF Policy on Character Sets and Languages [RFC 2277].
AAAプロトコルは、整数、列挙、テキスト文字列、IPアドレス、および日付/時刻などの単純な属性のデータ型を、サポートしなければなりません。 AAAプロトコルは、複雑な構造化データ型のいくつかのサポートを提供しなければなりません。 IPアドレスは、AAAプロトコル内で実行される限り、プロトコルは、IPv4とIPv6 [IPV6]アドレスの両方をサポートしなければなりません。テキスト情報は、AAAプロトコル内で実施される限り、プロトコルは、文字セットと言語[RFC 2277]にIETFポリシーを遵守しなければなりません。
At a minimum, the AAA protocol MUST support, or be easily extended to support, the set of attributes supported by RADIUS [RADIUS] and RADIUS Accounting [RADIUS-ACCOUNTING]. If the base AAA protocol does not support this complete set of attributes, then an extension to that protocol MUST be defined which supports this set.
最低でも、AAAプロトコルがサポートしなければならない、または容易に、RADIUS [RADIUS]とRADIUSアカウンティング[RADIUSアカウンティング]によってサポートされる属性のセットをサポートするように拡張されます。ベースAAAプロトコルは、この属性の完全なセットをサポートしていない場合は、そのプロトコルの拡張は、このセットをサポートする定義されなければなりません。
NAS and AAA development is always progressing. In order to prevent the AAA protocol from being a limiting factor in NAS and AAA Server development, the AAA protocol MUST provide a built-in extensibility mechanism, which MUST include a means for adding new standard attribute extensions. This MUST include a method for registering or requesting extensions through IANA, so that long-term working group involvement is not required to create new attribute types. Ideally, the AAA protocol SHOULD separate specification of the transport from specification of the attributes.
NASとAAAの開発は常に進められています。 NASおよびAAAサーバの開発を制限する要因であることから、AAAプロトコルを防ぐために、AAAプロトコルは、内蔵の新標準属性の拡張機能を追加するための手段を含まなければならない拡張メカニズムを提供しなければなりません。これは、長期的なワーキンググループの関与が新しい属性タイプを作成する必要がないように、IANAによって拡張を登録または要求するための方法を含まなければなりません。理想的には、AAAプロトコルは、属性の仕様から輸送の仕様を分離すべきです。
The AAA protocol MUST include a means for individual vendors to add value through vendor-specific attributes and SHOULD include support for vendor-specific data types.
AAAプロトコルは、個々のベンダーは、ベンダー固有の属性を介して値を追加し、ベンダー固有のデータ型のサポートを含むべきであるための手段を含まなければなりません。
It is poor security practice for a NAS to communicate with an AAA server that is not trusted, and vice versa. The AAA protocol MUST provide mutual authentication between AAA server and NAS.
これは、NASが信頼されていないAAAサーバ、およびその逆と通信するための貧弱なセキュリティプラクティスです。 AAAプロトコルは、AAAサーバとNASの間で相互認証を提供しなければなりません。
At a minimum, the AAA protocol SHOULD support use of a secret shared pairwise between each NAS and AAA server to mutually verify identity. This is intended for small-scale deployments. The protocol MAY provide stronger mutual security techniques.
最低でも、AAAプロトコルは互いに身元を確認するために、各NASとAAAサーバ間の共有秘密ペアワイズの使用をサポートしなければなりません。これは、小規模な展開を対象としています。プロトコルは、より強力な相互セキュリティ技術を提供することができます。
AAA server/NAS identity verification based solely on shared secrets can be difficult to deploy properly at large scale, and it can be tempting for NAS operators to use a single shared secret (that rarely changes) across all NAS's. This can lead to an easy compromise of the secret. Therefore, the AAA protocol MUST also support mutual verification of identity using a public-key infrastructure that supports expiration and revocation of keys.
共有秘密のみに基づいてAAAサーバ/ NASの本人確認は、大規模で適切に展開するのが難しいことができ、およびNASのオペレーターがすべてのNASの間で単一の共有秘密を（めったに変化しないもの）を使用することは魅力的なことができます。これは秘密の容易な妥協につながることができます。したがって、AAAプロトコルはまた、キーの有効期限と失効をサポートし、公開鍵インフラストラクチャを使用して身元の相互認証をサポートしなければなりません。
Some attributes are more operationally sensitive than others. Also, in a multi-domain scenario, attributes may be inserted by servers from different administrative domains. Therefore, the AAA protocol
一部の属性は、より運用敏感他よりあります。また、マルチドメインのシナリオでは、属性が異なる管理ドメインからサーバによって挿入されてもよいです。したがって、AAAプロトコル
MUST support selective encryption of attributes on an attribute-by-attribute basis, even within the same message. This requirement applies equally to Authentication, Authorization, and Accounting data.
でも、同じメッセージの中に、属性ごとの属性毎に属性を選択的に暗号化をサポートしなければなりません。この要件は、認証、認可、アカウンティングデータにも同様に適用されます。
End users who are requesting network access through a NAS will present various types of credentials. It is the purpose of the AAA protocol to transport these credentials between the NAS and the AAA server.
NASを介してネットワークへのアクセスを要求しているエンドユーザーは、資格情報の様々な種類を紹介します。 NASとAAAサーバの間でこれらの資格情報を輸送するAAAプロトコルの目的です。
The AAA protocol MUST support transport of credentials from the AAA server to the NAS, between the User and the NAS, and between the NAS and the AAA server.
AAAプロトコルは、ユーザーとNASの間、およびNASとAAAサーバの間で、NASにAAAサーバからの資格情報の転送をサポートしなければなりません。
The AAA protocol MUST support re-authentication at any time during the course of a session, initiated from either the NAS or the AAA server. This is a requirement of CHAP [CHAP].
AAAプロトコルは、NASまたはAAAサーバのいずれかから開始され、セッション中にいつでも再認証をサポートしなければなりません。これは、CHAP [CHAP]の要件です。
The AAA protocol MUST be able to support multi-phase authentication methods, including but not limited to support for:
AAAプロトコルが支援に限定されるものではないが、多相認証方法をサポートすることができなければなりません。
- Text prompting from the NAS to the user
- テキストのユーザにNASから求めます
- A series of binary challenges and responses of arbitrary length
- 任意の長さのバイナリチャレンジとレスポンスの一連
- An authentication failure reason to be transmitted from the NAS to the user
- ユーザーにNASから送信される認証失敗の理由
- Callback to a pre-determined phone number
- 所定の電話番号へのコールバック
Security protocol development is going on constantly as new threats are identified and better cracking methods are developed. Today's secure authentication methods may be proven insecure tomorrow. The AAA protocol MUST provide some support for addition of new authentication credential types.
新しい脅威が識別され、より良いクラッキング方法が開発されるセキュリティプロトコルの開発は常に起こっています。今日の安全な認証方法は、安全でない明日証明することができます。 AAAプロトコルは、新しい認証クレデンシャルタイプを追加するためのいくつかのサポートを提供しなければなりません。
In addition to the minimum attribute set, the AAA protocol must support and define attributes that provide the following functions:
最小限の属性セットに加えて、AAAプロトコルをサポートし、以下の機能を提供する属性を定義する必要があります。
Many authentication protocols are defined within the framework of PPP. The AAA protocol MUST be able to act as an intermediary protocol between the authenticate and the authenticator for the following authentication protocols:
多くの認証プロトコルはPPPの枠組みの中で定義されています。 AAAプロトコルは、次の認証プロトコルの認証と認証者の間の仲介プロトコルとして作用できなければなりません。
- PPP Password Authentication Protocol [PPP]
- PPPパスワード認証プロトコル[PPP]
- PPP Challenge Handshake Authentication Protocol [CHAP]
- PPPチャレンジハンドシェイク認証プロトコル[CHAP]
- PPP Extensible Authentication Protocol [EAP]
- PPP拡張認証プロトコル[EAP]
The following are common types of credentials used for user identification. The AAA protocol MUST be able to carry the following types of identity credentials:
以下は、ユーザーの識別に使用する資格情報の一般的なタイプです。 AAAプロトコルは、アイデンティティクレデンシャルの次のタイプを運ぶことができなければなりません。
- A user name in the form of a Network Access Identifier [NAI].
- ネットワークアクセス識別子[NAI]の形式でユーザー名。
- An Extensible Authentication Protocol [EAP] Identity Request Type packet.
- 拡張認証プロトコル[EAP]アイデンティティ要求タイプのパケット。
- Telephony dialing information such as Dialed Number Identification Service (DNIS) and Caller ID.
- そのようなダイヤル番号識別サービス（DNIS）と発信者IDなどの情報をダイヤル電話。
If a particular type of authentication credential is not needed for a particular user session, the AAA protocol MUST NOT require that dummy credentials be filled in. That is, the AAA protocol MUST support authorization by identification or assertion only.
認証資格情報の特定の種類は、特定のユーザーセッションのために必要されていない場合は、AAAプロトコルは、ダミーのクレデンシャルを充填することを要求してはなりません。つまり、AAAプロトコルは、識別のみアサーションによる認証をサポートしなければなりません。
The following are common types of credentials used for authentication. The AAA protocol MUST be able to carry the following types of authenticating credentials at a minimum:
認証に使用する資格情報の一般的な種類は次のとおり。 AAAプロトコルは、最低でも認証クレデンシャルの以下のタイプを運ぶことができなければなりません。
- A secret or password.
- 秘密のパスワード。
- A response to a challenge presented by the NAS to the user
- ユーザーにNASによって提示された課題への対応
- A one-time password
- ワンタイムパスワード
- An X.509 digital certificate [X.509]
- X.509デジタル証明書[X.509]
- A Kerberos v5 ticket [KERBEROS]
- ケルベロスV5チケット[KERBEROS]
Where passwords are used as authentication credentials, the AAA protocol MUST provide a secure means of hiding the password from intermediates in the AAA conversation. Where challenge/response mechanisms are used, the AAA protocol MUST also prevent against replay attacks.
パスワードが認証証明書として使用されている場合は、AAAプロトコルは、AAAの会話の中で中間体からパスワードを隠すの安全な手段を提供しなければなりません。チャレンジ/レスポンスメカニズムを使用する場合、AAAプロトコルはまた、リプレイ攻撃を防止しなければなりません。
In all cases, the protocol MUST specify that authorization data sent from the NAS to the AAA server is to be regarded as information or "hints", and not directives. The AAA protocol MUST be designed so that the AAA server makes all final authorization decisions and does not depend on a certain state being expected by the NAS.
すべての場合において、プロトコルは、AAAサーバにNASから送信された認証データを指定しなければならない情報または「ヒント」、としないディレクティブとしてみなされるべきです。 AAAサーバは、すべての最終認可決定を行い、NASが期待されている特定の状態に依存しないように、AAAプロトコルを設計する必要があります。
The AAA protocol MUST support dynamic re-authorization at any time during a user session. This re-authorization may be initiated in either direction. This dynamic re-authorization capability MUST include the capability to request a NAS to disconnect a user on demand.
AAAプロトコルは、ユーザーセッション中にいつでも動的再認証をサポートしなければなりません。この再認証は、どちらの方向に開始することができます。この動的再認証機能は、オンデマンドでユーザを切断するためにNASを要求する機能を含まなければなりません。
Resource Management MUST be supported on demand by the NAS or AAA Server at any time during the course of a user session. This would be the ability for the NAS to allocate and deallocate shared resources from a AAA server servicing multiple NASes. These resources may include, but are not limited to; IP addresses, concurrent usage limits, port usage limits, and tunnel limits. This capability should have error detection and synchronization features that will recover state after network and system failures. This may be accomplished by session information timeouts and explicit interim status and disconnect messages. There should not be any dependencies on the Accounting message stream, as per current practices.
リソース管理は、ユーザーセッションの進行中にいつでもNASまたはAAAサーバによってオンデマンドでサポートしなければなりません。これは、複数のNASをサービスするAAAサーバから共有リソースを割り当て、割り当て解除するNASのための能力だろう。これらのリソースは含まれるが、これらに限定されません。 IPアドレス、同時使用制限、ポート使用制限、およびトンネルの制限。この機能は、ネットワークやシステム障害後の状態を回復するエラー検出および同期機能を備えていなければなりません。これは、セッション情報のタイムアウトと明示的な中間状態と切断メッセージによって達成することができます。現在の慣行に従って、会計メッセージストリーム上の任意の依存関係があってはなりません。
This feature is primarily intended for NAS-local network resources. In a proxy or multi-domain environment, resource information should only be retained by the server doing the allocation, and perhaps it's backups. Authorization resources in remote domains should use the dynamic authorization features to change and revoke authorization status.
この機能は、主に、NAS-ローカルネットワークリソースを対象としています。プロキシまたはマルチドメイン環境では、リソース情報にのみ割り当てを行うサーバーによって保持されなければならない、そしておそらくそれはバックアップです。リモートドメインでの認証資源は、認証ステータスを変更し、取り消すために、動的認証機能を使用する必要があります。
The AAA protocol serves as a primary means of gathering data used for making Policy decisions for network access. Therefore, the AAA protocol MUST allow network operators to make policy decisions based on the following parameters:
AAAプロトコルは、ネットワークアクセスのポリシー決定を行うために使用される収集データの主な手段として機能します。したがって、AAAプロトコルは、ネットワーク事業者は、次のパラメータに基づいて政策決定を行うために許可する必要があります。
- Time/day restrictions. The AAA protocol MUST be able to provide an unambiguous time stamp, NAS time zone indication, and date indication to the AAA server in the Authorization information.
- 時間/日の制限。 AAAプロトコルは、認証情報のAAAサーバに明確なタイムスタンプ、NAS時間帯表示、及び日付の表示を提供できなければなりません。
- Location restrictions: The AAA protocol MUST be able to provide an unambiguous location code that reflects the geographic location of the NAS. Note that this is not the same type of thing as either the dialing or dialed station.
- 場所の制限：AAAプロトコルはNASの地理的位置を反映する明確な位置コードを提供することができなければなりません。これは、ダイヤルまたはダイヤルした駅のいずれかとの事の同じタイプではないことに注意してください。
- Dialing restrictions: The AAA protocol MUST be able to provide accurate dialed and dialing station indications.
- ダイヤル制限：AAAプロトコルは、正確なダイヤルとダイヤル局指示を提供することができなければなりません。
- Concurrent login limitations: The AAA protocol MUST allow an AAA Server to limit concurrent logins by a particular user or group of users. This mechanism does not need to be explicitly built into the AAA protocol, but the AAA protocol must provide sufficient authorization information for an AAA server to make that determination through an out-of-band mechanism.
- 同時ログイン制限：AAAプロトコルは、AAAサーバは、特定のユーザまたはユーザグループによる同時ログインを制限することを可能にしなければなりません。このメカニズムは、明示的にAAAプロトコルに組み込まれている必要はありませんが、AAAプロトコルは、アウトオブバンドメカニズムを介してその決意をするAAAサーバに十分な認証情報を提供する必要があります。
The AAA protocol is used to enforce policy at the NAS. Essentially, on granting of access, a particular access profile is applied to the user's session. The AAA protocol MUST at a minimum provide a means of applying profiles containing the following types of information:
AAAプロトコルはNASでポリシーを適用するために使用されます。基本的に、アクセスを許可するには、特定のアクセスプロファイルは、ユーザーのセッションに適用されます。 AAAプロトコルは、最低限次のタイプの情報を含むプロファイルを適用する手段を提供する必要があります。
- IP Address assignment: The AAA protocol MUST provide a means of assigning an IPv4 or IPv6 address to an incoming user.
- IPアドレスの割り当て：AAAプロトコルは、着信ユーザにIPv4またはIPv6アドレスを割り当てる手段を提供しなければなりません。
- Protocol Filter application: The AAA protocol MUST provide a means of applying IP protocol filters to user sessions. Two different methods MUST be supported.
- プロトコルフィルタの適用：AAAプロトコルは、ユーザーセッションにIPプロトコルフィルタを適用する手段を提供しなければなりません。 2つの異なる方法がサポートしなければなりません。
First, the AAA protocol MUST provide a means of selecting a protocol filter by reference to an identifier, with the details of the filter action being specified out of band. The AAA protocol SHOULD define this out-of-band reference mechanism.
まず、AAAプロトコルはフィルタ操作の詳細はバンドのうち、指定された状態で、識別子を参照することにより、プロトコルフィルタを選択する手段を提供しなければなりません。 AAAプロトコルは、このアウトオブバンド基準機構を定義する必要があります。
Second, the AAA protocol MUST provide a means of passing a protocol filter by value. This means explicit passing of pass/block information by address range, TCP/UDP port number, and IP protocol number at a minimum.
第二、AAAプロトコルは値によって、プロトコルフィルタを通過させる手段を提供しなければなりません。これは、最小のアドレス範囲、TCP / UDPポート番号、及びIPプロトコル番号によってパス/ブロック情報の明示的な通過を意味します。
- Compulsory Tunneling: The AAA protocol MUST provide a means of directing a NAS to build a tunnel or tunnels to a specified end- point. It MUST support creation of multiple simultaneous tunnels in a specified order. The protocol MUST allow, at a minimum, specification of the tunnel endpoints, tunneling protocol type, underlying tunnel media type, and tunnel authentication credentials (if required by the tunnel type). The AAA protocol MUST support at least the creation of tunnels using the L2TP [L2TP], ESP [ESP], and AH [AH] protocols. The protocol MUST provide means of adding new tunnel types as they are standardized.
- 強制トンネリング：AAAプロトコルは、指定されたエンドポイントへのトンネルまたはトンネルを構築するためにNASを指示する手段を提供しなければなりません。これは、指定された順序で複数の同時トンネルの作成をサポートしなければなりません。 （トンネル型で必要な場合）プロトコルは、最低でも、トンネルエンドポイントの指定を可能にトンネリング・プロトコル・タイプ、下地トンネルメディアタイプ、トンネル認証証明しなければなりません。 AAAプロトコルはL2TP [L2TP]、ESP [ESP]、およびAH [AH]プロトコルを使用してトンネルの少なくとも作成をサポートしなければなりません。プロトコルは、それらが標準化されているように新しいトンネルタイプを追加する手段を提供しなければなりません。
- Routing: The AAA protocol MUST provide a means of assigning a particular static route to an incoming user session.
- ルーティング：AAAプロトコルは、着信ユーザセッションに特定の静的ルートを割り当てる手段を提供しなければなりません。
- Expirations/timeouts: The AAA protocol MUST provide a means of communication session expiration information to a NAS. Types of expirations that MUST be supported are: total session time, idle time, total bytes transmitted, and total bytes received.
- 有効期限/タイムアウト：AAAプロトコルはNASへの通信セッションの有効期限情報の手段を提供しなければなりません。サポートしなければならない有効期限のタイプがある：総セッション時間、アイドル時間、送信される総バイト数、受信した総バイト数。
- Quality of Service: The AAA protocol MUST provide a means for supplying Quality of Service parameters to the NAS for individual user sessions.
- サービス品質：AAAプロトコルは、個々のユーザセッションのNASにサービス品質パラメータを供給するための手段を提供しなければなりません。
The AAA protocol is a means for network operators to perform management of network resources. The AAA protocol MUST provide a means of collecting resource state information, and controlling resource allocation for the following types of network resources.
AAAプロトコルは、ネットワークオペレータは、ネットワークリソースの管理を行うための手段です。 AAAプロトコルは、資源状態情報を収集し、ネットワークリソースの以下のタイプのリソース割り当てを制御する手段を提供しなければなりません。
- Network bandwidth usage per session, including multilink sessions.
- マルチセッションを含むセッションごとのネットワーク帯域幅の使用量、。
- Access port usage, including concurrent usage and usage pools.
- 同時使用および使用方法のプールを含むアクセスポートの使用状況、。
- Connect time.
- 時間を接続します。
- IP Addresses and pools.
- IPアドレスとプール。
- Compulsory tunnel limits.
- 強制トンネルの制限。
When an AAA protocol passes credentials that will be used to authenticate compulsory tunnels, the AAA protocol MUST provide a means of securing the credentials from end-to-end of the AAA conversation. The AAA protocol MUST also provide protection against replay attacks in this situation.
AAAプロトコルは強制的トンネルを認証するために使用される資格証明を通過する際に、AAAプロトコルは、エンドツーエンドのAAA会話から資格情報を確保する手段を提供しなければなりません。 AAAプロトコルはまた、このような状況では、リプレイ攻撃に対する保護を提供しなければなりません。
The accounting and auditing functions of the AAA protocol are used for network planning, resource management, policy decisions, and other functions that require accurate knowledge of the state of the NAS. NAS operators need to be able to engineer their network usage measurement systems to a predictable level of accuracy. Therefore, an AAA protocol MUST provide a means of guaranteed delivery of accounting information between the NAS and the AAA Server(s).
AAAプロトコルの課金及び監査機能は、ネットワークプランニング、リソース管理、政策決定、およびNASの状態の正確な知識を必要とする他の機能に使用されます。 NASオペレータは、精度の予測可能なレベルへのネットワーク使用量測定システムを操作できるようにする必要があります。したがって、AAAプロトコルはNASとAAAサーバ間の課金情報の配信保証の手段を提供しなければなりません。
NAS operators often require a real time view onto the status of sessions served by a NAS. Therefore, the AAA protocol MUST support real-time delivery of accounting and auditing information. In this context, real time is defined as accounting information delivery beginning within one second of the triggering event.
NAS事業者は、多くの場合、NASによって提供されるセッションのステータスの上にリアルタイム表示が必要です。したがって、AAAプロトコルは、課金及び監査情報のリアルタイム配信をサポートしなければなりません。この文脈では、実際の時間は、トリガイベントの1秒以内に開始する会計情報の配信として定義されます。
The AAA protocol SHOULD also support delivery of stored accounting and auditing information in batches (non-real time).
AAAプロトコルはまた、バッチに格納された課金及び監査情報の配信（ノンリアルタイム）をサポートすべきです。
There may be delays associated with the delivery of accounting information. The NAS operator will desire to know the time an event actually occurred, rather than simply the time when notification of the event was received. Therefore, the AAA protocol MUST carry an unambiguous time stamp associated with each accounting event. This time stamp MUST be unambiguous with regard to time zone. Note that this assumes that the NAS has access to a reliable time source.
会計情報の配信に関連する遅延があるかもしれません。 NASのオペレータは、イベントが実際に発生した時間を知りたいのではなく、イベントの通知を受信しただけで時間になります。したがって、AAAプロトコルは、各課金イベントに関連付けられている明確なタイムスタンプを運ばなければなりません。このタイムスタンプは、タイムゾーンに関して明確なでなければなりません。これは、NASは、信頼できるタイムソースへのアクセス権を持っていることを前提としています。
At a minimum, the AAA protocol MUST support delivery of accounting information triggered by the following events:
最低でも、AAAプロトコルは、以下のイベントによってトリガされる課金情報の配信をサポートしなければなりません。
- Start of a user session
- ユーザーセッションのスタート
- End of a user session
- ユーザーセッションの終了
- Expiration of a predetermined repeating time interval during a user session. The AAA protocol MUST provide a means for the AAA server to request that a NAS use a certain interval accounting time.
- ユーザセッション中に所定の繰り返し時間間隔の終了。 AAAプロトコルは、AAAサーバは、NASが一定間隔会計時間を使用することを要求するための手段を提供しなければなりません。
- Dynamic re-authorization during a user session (e.g., new resources being delivered to the user)
- ユーザーセッション中に動的な再認証（例えば、新しいリソースがユーザに配信されています）
- Dynamic re-authentication during a user session
- ユーザーセッション中に動的な再認証
NAS operators need to maintain an accurate view onto the status of sessions served by a NAS, even through failure of an AAA server. Therefore, the AAA protocol MUST support a means of requesting current session state and accounting from the NAS on demand.
NAS事業者であってもAAAサーバの故障により、NASによって提供されるセッションのステータスに正確なビューを維持する必要があります。したがって、AAAプロトコルは、現在のセッション状態を要求し、要求に応じてNASから会計の手段をサポートしなければなりません。
At a minimum, the AAA protocol MUST support delivery of the following types of accounting/auditing data:
最低でも、AAAプロトコルは、会計/監査データの次の種類の配信をサポートしなければなりません。
- All parameters used to authenticate a session.
- すべてのパラメータは、セッションを認証するために使用されます。
- Details of the authorization profile that was applied to the session.
- セッションに適用された認可プロファイルの詳細。
- The duration of the session.
- セッションの期間。
- The cumulative number of bytes sent by the user during the session.
- セッション中にユーザによって送信されたバイトの累積数。
- The cumulative number of bytes received by the user during the session.
- セッション中にユーザが受信したバイトの累積数。
- The cumulative number of packets sent by the user during the session.
- セッション中にユーザによって送信されたパケットの累積数。
- The cumulative number of packets received by the user during the session.
- セッション中にユーザによって受信されたパケットの累積数。
- Details of the access protocol used during the session (port type, connect speeds, etc.)
- セッション中に使用されるアクセスプロトコルの詳細（ポートタイプは、等速度に接続します）
Note that accounting and auditing data are operationally sensitive information. The AAA protocol MUST provide a means to assure end-to-end integrity of this data. The AAA protocol SHOULD provide a means of assuring the end-to-end confidentiality of this data.
会計と監査データが運用上の機密情報であることに注意してください。 AAAプロトコルは、このデータのエンドツーエンドの完全性を保証する手段を提供しなければなりません。 AAAプロトコルは、このデータのエンドツーエンドの機密性を保証する手段を提供すべきです。
Network operators use accounting data for network planning, resource management, and other business-critical functions that require confidence in the correctness of this data. The AAA protocol SHOULD provide a mechanism to ensure that the source of accounting data cannot easily repudiate this data after transmission.
ネットワークオペレータは、ネットワークプランニング、リソース管理、およびこのデータの正しさに自信を必要とする他のビジネスに不可欠な機能のための会計データを使用します。 AAAプロトコルは、会計データのソースを容易に送信した後、このデータを否認することができないことを保証するためのメカニズムを提供しなければなりません。
This document does not specify any requirements for device management protocols.
この文書では、デバイス管理プロトコルのいずれかの要件を指定していません。
Many of the requirements in this document first took form in Glen Zorn's, "Yet Another Authentication Protocol (YAAP)" document, for which grateful acknowledgment is made.
この文書の要求事項の多くは最初、グレンツォルンの形をした「もう一つの認証プロトコル（YAAP）」文書は、感謝している承認のために作られています。
See above for security requirements for the NAS AAA protocol.
NAS AAAプロトコルのためのセキュリティ要件については上記を参照してください。
Where an AAA architecture spans multiple domains of authority, AAA information may need to cross trust boundaries. In this situation, a NAS might operate as a shared device that services multiple administrative domains. Network operators are advised take this into consideration when deploying NAS's and AAA Servers.
AAAアーキテクチャが権限の複数のドメインにまたがる場合は、AAA情報は、信頼境界を横断する必要があるかもしれません。このような状況では、NASは、複数の管理ドメインにサービスを提供する共有デバイスとして動作する場合があります。ネットワークオペレータは、NASのとAAAサーバを展開するときは、この点を考慮して取ることをお勧めします。
This document does not directly specify any IANA considerations. However, the following recommendations are made:
このドキュメントは、直接任意のIANA問題を指定していません。ただし、以下の提言が行われます。
Future development and extension of an AAA protocol will be made much easier if new attributes and values can be requested or registered directly through IANA, rather than through an IETF Standardization process.
新しい属性と値が要求されたかというIETF標準化プロセスを通してよりも、IANAから直接登録することができるならば、将来の開発およびAAAプロトコルの拡張は、はるかに容易に行われます。
The AAA protocol might use enumerated values for some attributes, which enumerate already-defined IANA types (such as protocol number). In these cases, the AAA protocol SHOULD use the IANA assigned numbers as the enumerated values.
AAAプロトコルは、（例えば、プロトコル番号など）は、すでに定義IANAタイプを列挙いくつかの属性のための列挙値を使用するかもしれません。これらのケースでは、AAAプロトコルは、列挙された値としてIANA割り当てられた番号を使用すべきです。
[AH] Kent, S. and R. Atkinson, "IP Authentication Header (AH)", RFC 2402, November 1998.
[AH]ケント、S.とR.アトキンソン、 "IP認証ヘッダ（AH）"、RFC 2402、1998年11月。
[CHAP] Simpson, J., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[CHAP]シンプソン、J.、 "PPPチャレンジハンドシェイク認証プロトコル（CHAP）"、RFC 1994、1996年8月。
[CONGEST] Floyd, S., "Congestion Control Principles", RFC 2914, Sept. 2000.
[混雑]フロイド、S.、 "輻輳制御の原理"、RFC 2914、2000年9月。
[EAP] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[EAP]ブルンク、L.及びJ. Vollbrecht、 "PPP拡張認証プロトコル（EAP）"、RFC 2284、1998年3月。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESP]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[KERBEROS] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[KERBEROS]コールズ、J.及びC.ノイマン、 "ケルベロスネットワーク認証サービス（V5）"、RFC 1510、1993年9月。
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPV6]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[L2TP] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Plater, "Layer Two Tunneling Protocol (L2TP)", RFC 2661, August 1999.
[L2TP] Townsley、W.、バレンシア、A.、ルーベンス、A.、ポール、G.、ソーン、G、Bのプラター、 "レイヤ2トンネリングプロトコル（L2TP）"、RFC 2661、1999年8月。
[NAI] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[NAI] Aboba、B.及びM. Beadles、 "ネットワークアクセス識別子"、RFC 2486、1999年1月。
[NAS-MODEL] Mitton, D. and M. Beadles, "Network Access Server Requirements Next Generation (NASREQNG) NAS Model", RFC 2881, July 2000.
[NAS-MODEL]ミトン、D.とM. Beadles、 "ネットワークアクセスサーバー要件次世代（NASREQNG）NASモデル"、RFC 2881、2000年7月。
[NAS-EXT] Mitton, D., "Network Access Servers Requirements: Extended RADIUS Practices", RFC 2882, July 2000.
[NAS-EXT]ミトン、D.、 "ネットワークアクセスサーバーの要件：拡張RADIUSプラクティス"、RFC 2882、2000年7月。
[PPP] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[PPP]シンプソン、W.、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[PPPOE] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999.
[PPPOE] Mamakos、L.、Lidlの、K.、Evarts、J.、カレル、D.、シモン、D.およびR.ウィーラー、 "PPPオーバーイーサネット（PPPoEを）送信するための方法"、RFC 2516、1999年2月。
[ROUTING-REQUIREMENTS] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[ルーティング要件]ベイカー、F.、 "IPバージョン4つのルータのための要件"、RFC 1812、1995年6月。
[TELNET] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[TELNET]ポステル、J.、およびJ.レイノルズ、 "テルネットプロトコル仕様"、STD 8、RFC 854、1983年5月。
[RFC 2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC 2277] Alvestrand、H.、 "文字セットと言語のIETF方針"、BCP 18、RFC 2277、1998年1月。
[X.509] ITU-T Recommendation X.509 (1997 E): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework, June 1997.
[X.509] ITU-T勧告X.509（1997年E）：情報技術 - 開放型システム間相互接続 - ディレクトリ：認証フレームワーク、1997年6月。
[RADIUS] Rigney, C., Rubens. A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[RADIUS] Rigney、C.、ルーベンス。 A.、シンプソン、W.とS. Willens、RFC 2138、1997年4月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"。
[RADIUS-ACCOUNTING] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
[RADIUSアカウンティング] Rigney、C.、 "RADIUSアカウンティング"、RFC 2139、1997年4月。
[ROAMING-REQUIREMENTS] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999.
[ローミング要件] Aboba、B.およびG.ゾルン、 "ローミングプロトコルを評価するための基準"、RFC 2477、1999年1月。
Mark Anthony Beadles SmartPipes, Inc. 565 Metro Place South Suite 300 Dublin, OH 43017
マーク・アンソニーBeadles SmartPipes、Inc.の565メトロ置き南スイート300ダブリン、OH 43017
Phone: 614-923-6200
電話番号：614-923-6200
David Mitton Nortel Networks 880 Technology Park Drive Billerica, MA 01821
デヴィッド・ミトンNortel Networksの880テクノロジーパークドライブビレリカ、MA 01821
Phone: 978-288-4570 EMail: dmitton@nortelnetworks.com
電話：978-288-4570 Eメール：dmitton@nortelnetworks.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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機能のための基金は現在、インターネット協会によって提供されます。