RFC3169 日本語訳
3169 Criteria for Evaluating Network Access Server Protocols. M.Beadles, D. Mitton. September 2001. (Format: TXT=35303 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Beadles
Request for Comments: 3169 SmartPipes, Inc.
Category: Informational D. Mitton
Nortel Networks
September 2001
用務員がコメントのために要求するワーキンググループM.をネットワークでつないでください: 3169年のSmartPipes Inc.カテゴリ: 情報のD.ミットンノーテルは2001年9月をネットワークでつなぎます。
Criteria for Evaluating Network Access Server Protocols
ネットワークアクセス・サーバープロトコルを評価する評価基準
Status of this Memo
この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)インターネット協会(2001)。 All rights reserved。
Abstract
要約
This document defines requirements for protocols used by Network Access Servers (NAS).
このドキュメントはNetwork Access Servers(NAS)によって使用されたプロトコルのための要件を定義します。
1. Requirements language
1. 要件言語
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [KEYWORDS].
そして、このドキュメント、「5月」というキーワードで「必須、「必須NOT」、「任意」の、そして、「お勧め」の“SHOULD"、「」、[キーワード]で説明されるように解釈されることになっていてください、」であるべきです
2. Introduction
2. 序論
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.
このドキュメントはNetwork Access Servers(NAS)によって使用されたプロトコルのための要件を定義します。 NASのものによって使用されたプロトコルは4つの空間に分割されるかもしれません: プロトコル、Networkプロトコル、AAAプロトコル、およびDevice Managementプロトコルにアクセスしてください。 このドキュメントの焦点が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]で見つけられるかもしれません。
3. Access Protocol Requirements
3. アクセス・プロトコル要件
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]
Beadles & Mitton Informational [Page 1] RFC 3169 Criteria for Evaluating NAS Protocols September 2001
プロトコル2001年9月にNASを評価する用務員とミットン情報[1ページ]のRFC3169Criteria
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].
電話プロトコルを持ち越しました。 2番目は広帯域の疑似電話がxDSLの上まで運ばれるプロトコルか例えばケーブルモデムにアクセスするということです。 これらのプロトコルは、カプセル化がイーサネット[PPPOE]の上のPPPなどのメソッドであると通常サポートします。 最終的に、トンネルを終えるNASのものによって使用された仮想のアクセス・プロトコルがあります。 このタイプのプロトコルに関する1つの例が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をサポートするという要件から免除されています。
4. Network Protocol Requirements
4. ネットワーク・プロトコル要件
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は[ルート設定-REQUIREMENTS]を固く守らなければなりませんが、NASであるデバイスによって課された追加議定書要件が全くありません。
5. AAA Protocol Requirements
5. AAAプロトコル要件
5.1. General protocol characteristics
5.1. 一般プロトコルの特性
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.
どんなAAAプロトコルもNASのもので使用した一般的特色が満たされなければならないのを確信していた状態で、あります。 認証/承認のための輸送要件が必ず会計/監査のためのそれらと同じであるというわけではないことに注意してください。 AAAプロトコル群は、同じ輸送を使用して、両方の機能のために議定書を作るかもしれませんが、これは厳密に必要ではありません。
5.1.1. Transport requirements
5.1.1. 輸送要件
5.1.1.1. Transport independence
5.1.1.1. 輸送独立
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]を使用して、新しいプロトコルへのゲートウェイは、移行を奨励するために実用的でなければなりません。 デザインはRFC2914[CONGEST]で輻輳制御推薦に従わなければなりません。
Beadles & Mitton Informational [Page 2] RFC 3169 Criteria for Evaluating NAS Protocols September 2001
プロトコル2001年9月にNASを評価する用務員とミットン情報[2ページ]のRFC3169Criteria
5.1.1.2. Scalability
5.1.1.2. スケーラビリティ
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のスケールものが現在、配布されています。 そして、ただ一つのサーバシステムは多くのポートを調整するかもしれません。 これは、それが. NASesとAAAサーバの間の多くの小型小包のほとんど一定の交換が小型小包の長期の交換のために1組のホストの間で絶え間なく最適化されるAAAプロトコル輸送SHOULDサポートであったならそこで極端でそうするかもしれないことを意味します。
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.
多くのポート、クライアント、および同時発生のセッションを支えるようにプロトコルを設計しなければなりません。 貧しいデザインに関する例はそれの値がそれが列を作るためにとても小さいメッセージ識別子と窓が負荷の下で包装するレセプションを含んでいるでしょう、潜在的長い会期、妥当な電流を収容できない対価、および将来の帯域幅の生涯中に頻繁に実行しなければならない高いオーバーヘッドで用法、およびコンピュータのプロセスを包装するほど小さいユニークなセッション識別子範囲。
5.1.1.3. Support for Multiple AAA Servers and Failure Recovery
5.1.1.3. 複数のAAAには、サーバと失敗が回復であるとサポートしてください。
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のものに備えなければなりません。 ロードバランシングメカニズムSHOULD、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プロセスの間、1ポイントの失敗を導入してはいけません。 AAAプロトコルは州の情報の損失なしでNASと与えられたAAAサーバとのどんなセッションもセカンダリサーバへのフェイルオーバーに許容しなければなりません。 このフェイルオーバーメカニズムSHOULD、AAAプロトコル自体に建てられてください。
5.1.1.4. Support for Multiple Administrative Domains
5.1.1.4. 複数の管理ドメインのサポート
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
操作されたNASのものは1つの権威で別の権威によって手術されたクライアントにネットワークアクセス・サービスを提供します、さらに別の権威によって操作されたネットワークの目的地に。 このタイプのアレンジメントは増加して重要です。 例えば、現在、ダイヤルローミングはほとんど遍在しているサービスです。 したがって、AAAプロトコルはAAAをサポートしなければなりません。
Beadles & Mitton Informational [Page 3] RFC 3169 Criteria for Evaluating NAS Protocols September 2001
プロトコル2001年9月にNASを評価する用務員とミットン情報[3ページ]のRFC3169Criteria
services that travel between multiple domains of authority. The AAA protocol MUST NOT use a model that assumes a single domain of authority.
権威の複数のドメインの間を移動するサービス。 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プロトコルはプロキシをサポートしなければなりません、そして、さらに、SHOULDは他のマルチドメインが仲介や紹介などの関係であるとサポートします。
The AAA protocol MUST also meet the protocol requirements specified in [ROAMING-REQUIREMENTS].
また、AAAプロトコルは[ROAMING-REQUIREMENTS]で指定されたプロトコル必要条件を満たさなければなりません。
5.1.2. Attribute-Value Protocol Model
5.1.2. 属性値プロトコルモデル
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の何年もの運用経験は、Attribute-値のプロトコルモデルがAAAデータの最適の表現であると立証しました。 プロトコルSHOULDはAAAデータのAttribute値の表現を使用します。 このドキュメントはそのようなモデルに就くでしょう。 AAAプロトコルがワイヤにおけるデータ表現としてこれを使用しないでも、Attribute-値は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のAttributesが(16ビット)であるとサポートしなければなりません、それぞれ最低64K(16ビット)の長さで。
5.1.2.1. Attribute Data Types
5.1.2.1. 属性データ型
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プロトコルの中でどこまで運ばれても、プロトコルは文字コードとLanguages[RFC2277]の上のIETF Policyに従わなければなりません。
5.1.2.2. Minimum Set of Attributes
5.1.2.2. 最小のセットの属性
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 Accounting[RADIUS-ACCOUNTING]によってサポートされた属性のセット)に広げられてください。 ベースAAAプロトコルがこの完全なセットの属性をサポートしないなら、そのプロトコルへのこれがそれのサポートを設定した拡大を定義しなければなりません。
Beadles & Mitton Informational [Page 4] RFC 3169 Criteria for Evaluating NAS Protocols September 2001
プロトコル2001年9月にNASを評価する用務員とミットン情報[4ページ]のRFC3169Criteria
5.1.2.3. Attribute Extensibility
5.1.2.3. 属性伸展性
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 Server開発であることを防ぐために、AAAプロトコルは内蔵の伸展性メカニズムを提供しなければなりません。(それは、新しい標準の属性拡大を加えるための手段を含まなければなりません)。 これはIANAを通した拡大を示すか、または要求するためのメソッドを含まなければなりません、長期のワーキンググループかかわり合いが新しい属性タイプを創造するのに必要でないように。 理想的に、AAAプロトコルSHOULDは属性の仕様と輸送の仕様を切り離します。
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プロトコルは個々のベンダーがベンダー特有の属性を通して価値を高める手段を含まなければなりません、そして、SHOULDはベンダー特有のデータ型のサポートを含んでいます。
5.1.3. Security Requirements
5.1.3. セキュリティ要件
5.1.3.1. Mutual Authentication
5.1.3.1. 互いの認証
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の間に互いの認証を供給しなければなりません。
5.1.3.2. Shared Secrets
5.1.3.2. 共有秘密キー
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プロトコルSHOULDは、互いに本人であることを確かめるために各NASとAAAサーバの間の秘密の共有された対状の使用をサポートします。 これは小規模の展開のために意図します。 プロトコルは、より強い互いのセキュリティのテクニックを提供するかもしれません。
5.1.3.3. Public Key Security
5.1.3.3. 公開鍵セキュリティ
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プロトコルはアイデンティティの互いの検証をサポートしなければなりません。
5.1.3.4. Encryption of Attributes
5.1.3.4. 属性の暗号化
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プロトコル
Beadles & Mitton Informational [Page 5] RFC 3169 Criteria for Evaluating NAS Protocols September 2001
プロトコル2001年9月にNASを評価する用務員とミットン情報[5ページ]のRFC3169Criteria
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.
基礎の、そして、同じメッセージの中で同等の近く属性属性における属性の選択している暗号化をサポートしなければなりません。 この要件は等しくAuthentication、Authorization、およびAccountingデータに適用されます。
5.2. Authentication and User Security Requirements
5.2. 認証とユーザセキュリティ要件
5.2.1. Authentication protocol requirements
5.2.1. 認証プロトコル要件
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プロトコルの目的です。
5.2.1.1. Bi-directional Authentication
5.2.1.1. 双方向の認証
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プロトコルはUserとNASと、NASとAAAサーバの間の資格証明書のAAAサーバからNASまでの輸送をサポートしなければなりません。
5.2.1.2. Periodic Re-Authentication
5.2.1.2. 周期的な再認証
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]の要件です。
5.2.1.3. Multi-phase Authentication
5.2.1.3. マルチフェーズ認証
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
- 任意の長さの一連の2進の挑戦と応答
- An authentication failure reason to be transmitted from the NAS
to the user
- NASからユーザまで伝えられるべき認証失敗理由
- Callback to a pre-determined phone number
- 予定された電話番号へのコールバック
5.2.1.4. Extensible Authentication Types
5.2.1.4. 広げることができる認証タイプ
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プロトコルは認証の新しい資格証明書タイプの追加の何らかのサポートを提供しなければなりません。
Beadles & Mitton Informational [Page 6] RFC 3169 Criteria for Evaluating NAS Protocols September 2001
プロトコル2001年9月にNASを評価する用務員とミットン情報[6ページ]のRFC3169Criteria
5.2.2. Authentication Attribute Requirements
5.2.2. 認証属性要件
In addition to the minimum attribute set, the AAA protocol must support and define attributes that provide the following functions:
最小の属性セットに加えて、AAAプロトコルは、以下の機能を提供する属性を、サポートして、定義しなければなりません:
5.2.2.1. PPP Authentication protocols
5.2.2.1. PPP Authenticationプロトコル
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チャレンジハンドシェイク式認証プロトコル[やつ]
- PPP Extensible Authentication Protocol [EAP]
- ppp拡張認証プロトコル[EAP]
5.2.2.2. User Identification
5.2.2.2. ユーザ登録名
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].
- Network Access Identifier[NAI]の形のユーザ名。
- An Extensible Authentication Protocol [EAP] Identity Request
Type packet.
- 拡張認証プロトコル[EAP]アイデンティティRequest Typeパケット。
- Telephony dialing information such as Dialed Number
Identification Service (DNIS) and Caller ID.
- Dialed Number Identification Service(DNIS)や発信番号表示の情報にダイヤルする電話。
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プロトコルは識別か主張だけで承認をサポートしなければなりません。
5.2.2.3. Authentication Credentials
5.2.2.3. 認証資格証明書
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
- ワンタイムパスワード
Beadles & Mitton Informational [Page 7] RFC 3169 Criteria for Evaluating NAS Protocols September 2001
プロトコル2001年9月にNASを評価する用務員とミットン情報[7ページ]のRFC3169Criteria
- An X.509 digital certificate [X.509]
- X.509のデジタル証明書[X.509]
- A Kerberos v5 ticket [KERBEROS]
- ケルベロスv5チケット[ケルベロス]
5.2.3. Authentication Protocol Security Requirements
5.2.3. 認証プロトコルセキュリティ要件
5.2.3.1. End-to-End Hiding of Credentials
5.2.3.1. 終わりから端への資格証明書の隠れること
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です。
5.3. Authorization, Policy, and Resource management
5.3. 承認、Policy、およびResource管理
5.3.1. Authorization Protocol Requirements
5.3.1. 承認プロトコル要件
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によって予想されるある状態に依存しません。
5.3.1.1. Dynamic Authorization
5.3.1.1. ダイナミックな承認
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に要求する能力を含まなければなりません。
5.3.1.2. Resource Management
5.3.1.2. 資源管理
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 Serverがいつでも、ユーザセッションのコースの間、要求に応じてリソースManagementをサポートしなければなりません。 これはNASが割り当てる能力でしょう、そして、deallocateは複数のNASesを調整するAAAサーバからのリソースを共有しました。 含むかもしれませんが、これらのリソースが制限されない、。 IPアドレス(同時発生の用法限界)は用法限界、およびトンネルの限界を移植します。 この能力には、ネットワークとシステム障害の後に状態を回復する誤り検出と同期機能があるべきです。 これは、セッション情報タイムアウトと明白な当座の状態によって達成されて、メッセージから切断するかもしれません。 Accountingメッセージストリームの上に少しの依存も現在の実務に従ってあるべきではありません。
Beadles & Mitton Informational [Page 8] RFC 3169 Criteria for Evaluating NAS Protocols September 2001
プロトコル2001年9月にNASを評価する用務員とミットン情報[8ページ]のRFC3169Criteria
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-企業内情報通信網リソースのために主として意図します。 プロキシかマルチドメイン環境で、リソース情報は配分をするサーバによって保有されるだけであるべきです、そして、恐らく、それはバックアップです。 遠く離れたドメインの承認リソースは承認状態を変えて、取り消すダイナミックな承認機能を使用するべきです。
5.3.2. Authorization Attribute Requirements
5.3.2. 承認属性要件
5.3.2.1. Authorization Attribute Requirements - Access Restrictions
5.3.2.1. 承認属性要件--アクセス制限
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プロトコルはネットワークアクセサリーのための作成Policy決定に使用される集会データのプライマリ手段として機能します。 したがって、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プロトコルは明白なタイムスタンプ、NAS時間帯の指示、および日付の指示をAuthorization情報のAAAサーバに提供できなければなりません。
- 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 Serverは特定のユーザかユーザー層で同時発生のログインを制限できなければなりません。 AAAプロトコルはこのメカニズムによって明らかに組み込まれる必要はありませんが、AAAプロトコルはAAAサーバがバンドで出ているメカニズムを通してそれを決断にすることができるくらいの承認情報を提供しなければなりません。
5.3.2.2. Authorization Attribute Requirements - Authorization Profiles
5.3.2.2. 承認属性要件--承認プロフィール
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 Address課題: AAAプロトコルはIPv4かIPv6にアドレスを割り当てる手段を入って来るユーザに提供しなければなりません。
Beadles & Mitton Informational [Page 9] RFC 3169 Criteria for Evaluating NAS Protocols September 2001
プロトコル2001年9月にNASを評価する用務員とミットン情報[9ページ]のRFC3169Criteria
- Protocol Filter application: The AAA protocol MUST provide a
means of applying IP protocol filters to user sessions. Two
different methods MUST be supported.
- Filterアプリケーションについて議定書の中で述べてください: 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プロトコルSHOULDはこのバンドで出ている参照メカニズムを定義します。
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.
2番目に、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に指示する手段を提供しなければなりません。 それは指定されたオーダーにおける複数の同時のトンネルの作成をサポートしなければなりません。 プロトコルは最小限でトンネル終点の仕様を許容しなければなりません、プロトコルタイプ、基本的なトンネルメディアタイプ、およびトンネル認証資格証明書(必要ならトンネルタイプによる)にトンネルを堀って。 L2TP[L2TP]、超能力[超能力]、およびAH[AH]プロトコルを使用して、AAAプロトコルは少なくともトンネルの作成をサポートしなければなりません。 プロトコルは彼らが標準化されるので新しいトンネルタイプを加える手段を提供しなければなりません。
- 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プロトコルは個々のユーザセッションのためにServiceパラメタのQualityをNASに供給するための手段を提供しなければなりません。
5.3.2.3. Resource Management Requirements
5.3.2.3. 資源管理要件
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.
- 1マルチリンクセッションを含むセッションあたりの帯域幅用法をネットワークでつないでください。
Beadles & Mitton Informational [Page 10] RFC 3169 Criteria for Evaluating NAS Protocols September 2001
プロトコル2001年9月にNASを評価する用務員とミットン情報[10ページ]のRFC3169Criteria
- Access port usage, including concurrent usage and usage pools.
- 同時発生の用法と用法プールを含むポート用法にアクセスしてください。
- Connect time.
- 接続時間。
- IP Addresses and pools.
- IP Addressesとプール。
- Compulsory tunnel limits.
- 強制的なトンネルの限界。
5.3.3. Authorization Protocol Security Requirements
5.3.3. 承認プロトコルセキュリティ要件
5.3.3.1. Security of Compulsory Tunnel Credentials
5.3.3.1. 強制的なトンネル資格証明書のセキュリティ
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プロトコルは反射攻撃に対する保護をこの状況に提供しなければなりません。
5.4. Accounting and Auditing Requirements
5.4. 会計学と会計監査学要件
5.4.1. Accounting Protocol Requirements
5.4.1. 会計プロトコル要件
5.4.1.1. Guaranteed Delivery
5.4.1.1. 荷渡しを保証します。
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 Server(s)の間に供給しなければなりません。
5.4.1.2. Real Time Accounting
5.4.1.2. リアルタイムの会計
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の中で引き金となる出来事の2番目を始める課金情報配送と定義されます。
5.4.1.3. Batch Accounting
5.4.1.3. バッチ会計
The AAA protocol SHOULD also support delivery of stored accounting and auditing information in batches (non-real time).
また、AAAプロトコルSHOULDはバッチ(非リアルタイム)における、保存された会計学と会計監査学情報の配送をサポートします。
Beadles & Mitton Informational [Page 11] RFC 3169 Criteria for Evaluating NAS Protocols September 2001
プロトコル2001年9月にNASを評価する用務員とミットン情報[11ページ]のRFC3169Criteria
5.4.1.4. Accounting Time Stamps
5.4.1.4. 会計時間スタンプ
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が頼もしい時間ソースに近づく手段を持っていると仮定することに注意してください。
5.4.1.5. Accounting Events
5.4.1.5. 会計イベント
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
- ユーザセッションの間のダイナミックな再認証
5.4.1.6. On-Demand Accounting
5.4.1.6. 要求次第の会計
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オペレータは、NASによって役立たれたセッションの状態に正確な視点を維持する必要があります、AAAサーバの失敗さえを通して。したがって、AAAプロトコルはオンデマンドのNASから現在のセッション状態と会計を要求する手段をサポートしなければなりません。
5.4.2. Accounting Attribute Requirements
5.4.2. 会計属性要件
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.
- セッションの持続時間。
Beadles & Mitton Informational [Page 12] RFC 3169 Criteria for Evaluating NAS Protocols September 2001
プロトコル2001年9月にNASを評価する用務員とミットン情報[12ページ]のRFC3169Criteria
- 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.)
- セッションの間に使用されるアクセス・プロトコルの詳細(タイプを移植してください、そして、速度などを接続してください)
5.4.3. Accounting Protocol Security Requirements
5.4.3. 会計プロトコルセキュリティ要件
5.4.3.1. Integrity and Confidentiality
5.4.3.1. 保全と秘密性
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プロトコルSHOULDは終わりから終わりへの秘密性にこのデータを保証する手段を提供します。
5.4.3.2. Auditibility
5.4.3.2. Auditibility
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プロトコルSHOULDは、会計データの源がトランスミッションの後に容易にこのデータを否認できないのを保証するためにメカニズムを提供します。
6. Device Management Protocols
6. デバイス管理プロトコル
This document does not specify any requirements for device management protocols.
このドキュメントはデバイス管理プロトコルのためのどんな要件も指定しません。
7. Acknowledgments
7. 承認
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ところで本書では形を取りました、と「さらに別の認証プロトコル(YAAP)」はどの感謝している承認をするように記録するか。
8. Security Considerations
8. セキュリティ問題
See above for security requirements for the NAS AAA protocol.
NAS AAAプロトコルのためのセキュリティ要件に関して上を見てください。
Beadles & Mitton Informational [Page 13] RFC 3169 Criteria for Evaluating NAS Protocols September 2001
プロトコル2001年9月にNASを評価する用務員とミットン情報[13ページ]のRFC3169Criteria
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がServersであると配布するときにはこれを考慮に入れてください。
9. IANA Considerations
9. IANA問題
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 Standardizationプロセスを通してというよりむしろ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プロトコルSHOULDは列挙された値としてIANA規定番号を使用します。
10. References
10. 参照
[AH] Kent, S. and R. Atkinson, "IP Authentication
Header (AH)", RFC 2402, November 1998.
[ああ] ケントとS.とR.アトキンソン、「IP認証ヘッダー(ああ)」、RFC2402、1998年11月。
[CHAP] Simpson, J., "PPP Challenge Handshake
Authentication Protocol (CHAP)", RFC 1994,
August 1996.
[ひびが切れます] シンプソン、J.、「pppチャレンジハンドシェイク式認証プロトコル(やつ)」、RFC1994、1996年8月。
[CONGEST] Floyd, S., "Congestion Control Principles",
RFC 2914, Sept. 2000.
[充血します] フロイド、2000年9月のS.、「輻輳制御プリンシプルズ」RFC2914。
[EAP] Blunk, L. and J. Vollbrecht, "PPP Extensible
Authentication Protocol (EAP)", RFC 2284,
March 1998.
1998年の[EAP]BlunkとL.とJ.Vollbrecht、「ppp拡張認証プロトコル(EAP)」、RFC2284行進。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating
Security Payload (ESP)", RFC 2406, November
1998.
[超能力] ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC
2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[KERBEROS] Kohl, J. and C. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510,
September 1993.
[ケルベロス] コールとJ.とC.ヌーマン、「ケルベロスネットワーク認証サービス(V5)」、RFC1510 1993年9月。
Beadles & Mitton Informational [Page 14] RFC 3169 Criteria for Evaluating NAS Protocols September 2001
プロトコル2001年9月にNASを評価する用務員とミットン情報[14ページ]のRFC3169Criteria
[IPV6] Deering, S. and R. Hinden, "Internet
Protocol, Version 6 (IPv6) Specification",
RFC 2460, December 1998.
[IPV6]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[L2TP] Townsley, W., Valencia, A., Rubens, A., Pall,
G., Zorn, G. and B. Plater, "Layer Two
Tunneling Protocol (L2TP)", RFC 2661, August
1999.
w.[L2TP]Townsley、バレンシア、A.、ルーベン(A.)は気がぬけます、ゾルン、G.、およびB.めっき工、G.、「層Twoはプロトコル(L2TP)にトンネルを堀っ」て、RFC2661、1999年8月。
[NAI] Aboba, B. and M. Beadles, "The Network Access
Identifier", RFC 2486, January 1999.
[NAI] AbobaとB.とM.用務員、「ネットワークアクセス識別子」、RFC2486、1999年1月。
[NAS-MODEL] Mitton, D. and M. Beadles, "Network Access
Server Requirements Next Generation
(NASREQNG) NAS Model", RFC 2881, July 2000.
[NAS-モデル]ミットンとD.とM.用務員、「ネットワークアクセス・サーバー要件次世代(NASREQNG)NASはモデル化する」RFC2881、2000年7月。
[NAS-EXT] Mitton, D., "Network Access Servers
Requirements: Extended RADIUS Practices", RFC
2882, July 2000.
[NAS-EXT]ミットン、D.、「アクセス・サーバー要件をネットワークでつないでください」 「拡張半径習慣」、RFC2882、2000年7月。
[PPP] Simpson, W., "The Point-to-Point Protocol
(PPP)", STD 51, RFC 1661, July 1994.
[ppp]シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、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.とエバーツとJ.と個人閲覧室とD.とシモンとD.とR.ウィーラー、「イーサネット(PPPoE)の上にpppを伝えるためのメソッド」、RFC2516、1999年2月。
[ROUTING-REQUIREMENTS] Baker, F., "Requirements for IP Version 4
Routers", RFC 1812, June 1995.
「IPバージョン4ルータのための要件」という[ルーティング要件]ベイカー、F.、RFC1812、1995年6月。
[TELNET] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC 854, May 1983.
[telnet] ポステル、J.、およびJ.レイノルズ(「telnetプロトコル仕様」、STD8、RFC854)は1983がそうするかもしれません。
[RFC 2277] Alvestrand, H., "IETF Policy on Character
Sets and Languages", BCP 18, RFC 2277,
January 1998.
[RFC2277] Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、RFC2277、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(1997E): 情報技術--オープン・システム・インターコネクション--ディレクトリ: 1997年6月の認証フレームワーク。
[RADIUS] Rigney, C., Rubens. A., Simpson, W. and S.
Willens, "Remote Authentication Dial In User
Service (RADIUS)", RFC 2138, April 1997.
[半径] Rigney、C.、ルーベン。 A.とシンプソンとW.とS.ウィレンス、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2138、1997年4月。
Beadles & Mitton Informational [Page 15] RFC 3169 Criteria for Evaluating NAS Protocols September 2001
プロトコル2001年9月にNASを評価する用務員とミットン情報[15ページ]のRFC3169Criteria
[RADIUS-ACCOUNTING] Rigney, C., "RADIUS Accounting", RFC 2139,
April 1997.
[半径会計] Rigney、C.、「半径会計」、RFC2139、1997年4月。
[ROAMING-REQUIREMENTS] Aboba, B. and G. Zorn, "Criteria for
Evaluating Roaming Protocols", RFC 2477,
January 1999.
[ローミング要件] AbobaとB.とG.ゾルン、「ローミングプロトコルを評価する評価基準」、RFC2477、1999年1月。
11. Authors' Addresses
11. 作者のアドレス
Mark Anthony Beadles SmartPipes, Inc. 565 Metro Place South Suite 300 Dublin, OH 43017
ダブリン、マークアンソニー用務員SmartPipes Inc.565の地下鉄の場所の南Suite300OH 43017
Phone: 614-923-6200
以下に電話をしてください。 614-923-6200
David Mitton Nortel Networks 880 Technology Park Drive Billerica, MA 01821
Driveビルリカ、デヴィッドミットンノーテルネットワーク880技術Park MA 01821
Phone: 978-288-4570 EMail: dmitton@nortelnetworks.com
以下に電話をしてください。 978-288-4570 メールしてください: dmitton@nortelnetworks.com
Beadles & Mitton Informational [Page 16] RFC 3169 Criteria for Evaluating NAS Protocols September 2001
プロトコル2001年9月にNASを評価する用務員とミットン情報[16ページ]のRFC3169Criteria
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Beadles & Mitton Informational [Page 17]
用務員でミットンInformationalです。[17ページ]
一覧
スポンサーリンク
