[要約] RFC 3169は、ネットワークアクセスサーバープロトコルの評価基準を提供するものであり、ネットワークアクセスサーバープロトコルの選択と実装のためのガイドラインを提供することを目的としています。
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.
Copyright（c）The Internet Society（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].
このドキュメントでは、キーワード「可能性」、「必要はない」、「オプション」、「推奨」、「必要」、「必要はない」は、[キーワード]で説明されているように解釈されるべきではありません。
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）が使用するプロトコルの要件を定義します。NASで使用されるプロトコルは、アクセスプロトコル、ネットワークプロトコル、AAAプロトコル、およびデバイス管理プロトコルの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] 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].
NASが使用するアクセスプロトコルには、3つの基本的なタイプがあります。1つ目は、モデムまたはターミナルアダプターまたは同様のデバイスを介してNASにインターフェイスする従来のテレフォニーベースのアクセスプロトコルです。これらのプロトコルは通常、非同期または同期PPP [PPP]をサポートしています。2番目は、たとえばXDSLまたはケーブルモデムに搭載されているブロードバンドの擬似四面体アクセスプロトコルです。これらのプロトコルは通常、イーサネット上のPPP [PPPOE]などのカプセル化方法をサポートしています。最後に、トンネルを終了するNASの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が上記のアクセスプロトコルのいずれかを介して複数のポイントツーポイントリンクを受け入れることをここで使用した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プロトコルの設計は、輸送に依存している必要があります。既存のインフラストラクチャは、UDPベースのプロトコル[RADIUS]を使用しています。新しいプロトコルへのゲートウェイは、移行を促進するために実用的でなければなりません。設計は、RFC 2914 [Commest]の輻輳制御の推奨事項に準拠する必要があります。
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が展開されています。また、単一のサーバーシステムが多数のポートを使用する場合があります。これは、極端に、Naseと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プロトコルは、2つ以上の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.
ある当局によって運営されている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プロトコルは、[Roaming-Requirements]で指定されたプロトコル要件も満たす必要があります。
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プロトコルは、複雑な構造化データ型のサポートも提供する必要があります。AAAプロトコル内でIPアドレスが携帯される場合は、プロトコルはIPv4とIPv6 [IPv6]アドレスの両方をサポートする必要があります。AAAプロトコル内でテキスト情報が掲載されている場合は、プロトコルは、文字セットと言語に関するIETFポリシーに準拠する必要があります[RFC 2277]。
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-ACCOUNTING]によってサポートされる一連の属性をサポートするか、簡単にサポートする必要があります。ベース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の開発は常に進行しています。AAAプロトコルがNASおよび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サーバー間の秘密の共有ペアワイズの使用をサポートして、IDを相互に検証する必要があります。これは、小規模な展開を目的としています。このプロトコルは、より強力な相互セキュリティ手法を提供する場合があります。
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 IDの検証は、大規模に適切に展開することが困難である可能性があり、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 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.
一部の属性は、他の属性よりも運用上敏感です。また、マルチドメインシナリオでは、異なる管理ドメインのサーバーによって属性を挿入することができます。したがって、AAAプロトコルは、同じメッセージ内であっても、属性ごとの属性ベースで属性の選択的暗号化をサポートする必要があります。この要件は、認証、承認、会計データに等しく適用されます。
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プロトコルは、AAAサーバーからNASへ、ユーザーとNASの間、および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サーバーのいずれかから開始されたセッション中にいつでも再認証をサポートする必要があります。これはチャップ[チャップ]の要件です。
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プロトコルは、次のタイプのID資格情報を運ぶことができなければなりません。
- A user name in the form of a Network Access Identifier [NAI].
- ネットワークアクセス識別子[NAI]の形式のユーザー名。
- An Extensible Authentication Protocol [EAP] Identity Request Type packet.
- 拡張可能な認証プロトコル[EAP] IDリクエストタイプパケット。
- 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
- 1回限りのパスワード
- An X.509 digital certificate [X.509]
- X.509デジタル証明書[X.509]
- A Kerberos v5 ticket [KERBEROS]
- 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.
すべての場合において、プロトコルは、NASからAAAサーバーに送信された承認データが、指令ではなく情報または「ヒント」と見なされることを指定する必要があります。AAAプロトコルは、AAAサーバーがすべての最終的な許可決定を下し、NASが予想される特定の状態に依存しないように設計する必要があります。
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が複数のNaseをサービスするAAAサーバーから共有リソースを割り当てて扱うことができることです。これらのリソースには含まれる場合がありますが、これらに限定されません。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-Local Networkリソースを対象としています。プロキシまたはマルチドメイン環境では、リソース情報は、割り当てを行うサーバーによってのみ保持される必要があります。おそらくそれはバックアップです。リモートドメインの承認リソースは、動的な承認機能を使用して、承認ステータスを変更および取り消す必要があります。
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.
このドキュメントの要件の多くは、Glen Zornの「さらに別の認証プロトコル（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] Kent、S。およびR. Atkinson、「IP認証ヘッダー（AH）」、RFC 2402、1998年11月。
[CHAP] Simpson, J., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[Chap] Simpson、J。、「PPP Challenge Handshake Authentication Protocol（Chap）」、RFC 1994、1996年8月。
[CONGEST] Floyd, S., "Congestion Control Principles", RFC 2914, Sept. 2000.
[Commest] Floyd、S。、「混雑制御原則」、RFC 2914、2000年9月。
[EAP] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[EAP] Blunk、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] Kent、S。およびR. Atkinson、「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.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[KERBEROS] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[Kerberos] Kohl、J。and C. Neuman、「The Kerberos Network Authentication Service（V5）」、RFC 1510、1993年9月。
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6] Deering、S。and 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.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、G.およびB. Plater、「レイヤー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] Mitton、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] Mitton、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.、Carreel、D.、Simone、D。、およびR. Wheeler、「PPPをイーサネット上に送信する方法（PPPOE）」、RFC 2516、1999年2月。
[ROUTING-REQUIREMENTS] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[Routing-Requirements] Baker、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[TELNET] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[Telnet] Postel、J。およびJ. Reynolds、「Telnetプロトコル仕様」、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]リグニー、C。、ルーベンス。A.、Simpson、W。およびS. Willens、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2138、1997年4月。
[RADIUS-ACCOUNTING] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
[Radius-Accounting] Rigney、C。、「Radius Accounting」、RFC 2139、1997年4月。
[ROAMING-REQUIREMENTS] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999.
[Roaming-Requirements] Aboba、B。およびG. Zorn、「ローミングプロトコルを評価するための基準」、RFC 2477、1999年1月。
Mark Anthony Beadles SmartPipes, Inc. 565 Metro Place South Suite 300 Dublin, OH 43017
マーク・アンソニー・ビードルズSmartPipes、Inc。565 Metro Place South Suite 300 Dublin、OH 43017
Phone: 614-923-6200
電話：614-923-6200
David Mitton Nortel Networks 880 Technology Park Drive Billerica, MA 01821
David Mitton Nortel Networks 880 Technology Park Drive Billerica、MA 01821
Phone: 978-288-4570 EMail: dmitton@nortelnetworks.com
電話：978-288-4570メール：dmitton@nortelnetworks.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。