RFC2882 日本語訳
2882 Network Access Servers Requirements: Extended RADIUS Practices.D. Mitton. July 2000. (Format: TXT=31426 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Mitton Request for Comments: 2882 Nortel Networks Category: Informational July 2000
コメントを求めるワーキンググループD.ミットンの要求をネットワークでつないでください: 2882 ノーテルはカテゴリをネットワークでつなぎます: 情報の2000年7月
Network Access Servers Requirements:
Extended RADIUS Practices
アクセス・サーバー要件をネットワークでつないでください: 拡張半径習慣
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 (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This document describes current practices implemented in NAS products that go beyond the scope of the RADIUS RFCs 2138, 2139 [1,2]. The purpose of this effort is to give examples that show the need for addressing and standardizing these types of ad-hoc functions. Since many of these features require a matching server support component, the ability to deploy and manage interoperable NAS and AAA server products is severely hindered.
このドキュメントはRADIUS RFCs2138、2139年[1、2]の範囲を越えるNAS製品の中に実装された現在の実務について説明します。 この取り組みの目的はこれらのタイプの臨時の関数を扱って、標準化する必要性を示している例を出すことです。 これらの特徴の多くが合っているサーバサポートコンポーネントを必要とするので、共同利用できるNASとAAAサーバ製品を配布して、管理する能力は厳しく妨げられます。
These practices are documented here to show functions that are obviously desired in developing future AAA protocols for NAS deployment.
これらの習慣は、NAS展開のために展開している将来のAAAプロトコルで明らかに望まれている機能を示しているためにここに記録されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Disclaimers . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Presentation . . . . . . . . . . . . . . . . . . . . . . 3 2. Attribute Usage . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Attribute Conflicts . . . . . . . . . . . . . . . . . . . 4 2.2. Attribute Value Conflicts . . . . . . . . . . . . . . . . 4 2.2.1 Vendor Specific Enumerations Proposal . . . . . . . . . . 4 2.3 Vendor Specific Attribute Usage . . . . . . . . . . . . . 5 2.3.1 VSAs in use by clients: . . . . . . . . . . . . . . . . . 5 2.3.2 Clients that support multiple Vendors: . . . . . . . . . 5 3. Attribute Data Types . . . . . . . . . . . . . . . . . . . 6 4. New Messages . . . . . . . . . . . . . . . . . . . . . . . 7 5. Additional Functions . . . . . . . . . . . . . . . . . . . 7 5.1 Password Change . . . . . . . . . . . . . . . . . . . . . 8
1. 序論. . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 注意書き. . . . . . . . . . . . . . . . . . . . . . . 3 1.2。 プレゼンテーション. . . . . . . . . . . . . . . . . . . . . . 3 2。 用法. . . . . . . . . . . . . . . . . . . . . . 3 2.1を結果と考えてください。 闘争. . . . . . . . . . . . . . . . . . . 4 2.2を結果と考えてください。 クライアントで使用中のValue Conflicts. . . . . . . . . . . . . . . . 4 2.2.1Vendor Specific Enumerations Proposal. . . . . . . . . . 4 2.3Vendor Specific Attribute Usage. . . . . . . . . . . . . 5 2.3.1VSAsを結果と考えてください: . . . . . . . . . . . . . . . . . 5 2.3 複数のVendorsをサポートする.2人のクライアント: . . . . . . . . . 5 3. データ型. . . . . . . . . . . . . . . . . . . 6 4を結果と考えてください。 新しいメッセージ. . . . . . . . . . . . . . . . . . . . . . . 7 5。 追加機能. . . . . . . . . . . . . . . . . . . 7 5.1パスワード変化. . . . . . . . . . . . . . . . . . . . . 8
Mitton Informational [Page 1] RFC 2882 Extended RADIUS Practices July 2000
ミットン情報[1ページ]のRFC2882は2000年7月に半径習慣を表しました。
5.2 Authentication Modes . . . . . . . . . . . . . . . . . . . 8 5.3 Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.4 Pseudo Users . . . . . . . . . . . . . . . . . . . . . . . 9 6. Resource Management . . . . . . . . . . . . . . . . . . . . 9 6.1 Managed Resources . . . . . . . . . . . . . . . . . . . . . 9 6.2 Resource Management Messages . . . . . . . . . . . . . . . 10 6.3 Concurrent Logins . . . . . . . . . . . . . . . . . . . . . 10 6.4 Authorization Changes . . . . . . . . . . . . . . . . . . . 11 7. Policy Services . . . . . . . . . . . . . . . . . . . . . . 11 8. Accounting Extensions . . . . . . . . . . . . . . . . . . . 12 8.1 Auditing/Activity . . . . . . . . . . . . . . . . . . . . . 12 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . 13 11. Implementation Documents . . . . . . . . . . . . . . . . . 13 11.1. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.2. Servers . . . . . . . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . 14 13. Author's Address . . . . . . . . . . . . . . . . . . . . . 15 14. Full Copyright Statement . . . . . . . . . . . . . . . . . 16
5.2 認証モード. . . . . . . . . . . . . . . . . . . 8 5.3メニュー. . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.4疑似ユーザ.9 6。 承認が.117に変えるリソース管理. . . . . . . . . . . . . . . . . . . . 9 6.1管理資源. . . . . . . . . . . . . . . . . . . . . 9 6.2資源管理メッセージ. . . . . . . . . . . . . . . 10 6.3の同時発生のログイン. . . . . . . . . . . . . . . . . . . . . 10 6.4。 方針サービス. . . . . . . . . . . . . . . . . . . . . . 11 8。 拡大. . . . . . . . . . . . . . . . . . . 12 8.1監査/活動が.129であることを説明します。 結論. . . . . . . . . . . . . . . . . . . . . . . . 12 10。 セキュリティ問題. . . . . . . . . . . . . . . . . . 13 11。 実装ドキュメント. . . . . . . . . . . . . . . . . 13 11.1。 クライアント. . . . . . . . . . . . . . . . . . . . . . . . . 13 11.2。 サーバ. . . . . . . . . . . . . . . . . . . . . . . . . 14 12。 参照. . . . . . . . . . . . . . . . . . . . . . . . 14 13。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . 15 14。 完全な著作権宣言文. . . . . . . . . . . . . . . . . 16
1. Introduction
1. 序論
The RADIUS Working Group was formed in 1995 to document the protocol of the same name, and was chartered to stay within a set of bounds for dial-in terminal servers. Unfortunately the real world of Network Access Servers (NASes) hasn't stayed that small and simple, and continues to evolve at an amazing rate.
RADIUS作業部会は、1995年に同じ名前のプロトコルを記録するために形成されて、ダイヤルインのターミナルサーバのために1セットの領域の範囲内にとどまるためにチャーターされました。 Network Access Servers(NASes)の本当の世界は、そんなに小さくて、簡単な状態で滞在していなくて、残念ながら、驚くべき速度で発展し続けています。
This document shows some of the current implementations on the market have already outstripped the capabilities of the RADIUS protocol. A quite a few features have been developed completely outside the protocol. These features use the RADIUS protocol structure and format, but employ operations and semantics well beyond the RFC documents.
このドキュメントは、市販の現在の実装のいくつかが既にRADIUSプロトコルの能力を追い越したのを示します。 かなり多くの特徴がプロトコルの完全外で発生しました。 これらの特徴がRADIUSプロトコル構造と形式を使用して、唯一の雇用は、かなりRFCドキュメントを超えた操作と意味論です。
I learn of the details of these functions from reading industry manuals and often have to respond to them in competive bid specifications. As they become deployed in the field, they gather the force of de-facto standards.
私は、読書産業マニュアルからこれらの機能の詳細を知って、competive入札仕様書でしばしばそれらに応じなければなりません。 その分野で配布されるようになるのに従って、彼らはデファクト規格の力を集めます。
Because they have been done outside scope of the RFCs, they are vendor specific, and introduce significant problems in offering an interoperable product.
RFCsの範囲の外でそれらをしたので、彼らは、ベンダー特有であり、共同利用できる製品を提供する際に重大な問題を紹介します。
Mitton Informational [Page 2] RFC 2882 Extended RADIUS Practices July 2000
ミットン情報[2ページ]のRFC2882は2000年7月に半径習慣を表しました。
1.1. Disclaimers
1.1. 注意書き
The data and numbers in this document have been gleaned from public sources and vendor documents along the way. Actual implementation of many these features and variation from the documentation has not been confirmed.
道に沿って公共のソースとベンダードキュメントからデータと数を本書では収集してあります。 ドキュメンテーションからのこれらが特徴とする多く、変化の実際の実装は確認されていません。
This document is a snapshot of known practices at the time of writing. It is not intended to standardize these practices here, or keep this document current, beyond initial publication. While some detailed information is given, it is not the purpose of this document to directly or sufficiently describe the functions mentioned to the level of a complete functional specification.
このドキュメントはこれを書いている時点で知られている習慣のスナップです。 それは、ここでこれらの習慣を標準化するか、または初期の公表を超えて現在にこのドキュメントを保管することを意図しません。 または、何らかの詳細な情報を与えますが、それがこのドキュメントの目的でない、直接、完全な機能的な仕様のレベルに言われている機能について十分説明してください。
The author has not transcribed copyrighted material, and is not aware of whether any of these practices have of intellectual property restrictions.
作者は、著作権で保護されたものを転写していなくて、またこれらの習慣のどれかが知的所有権制限についてそうしたかどうかを意識していません。
Any numeric assignments or functional operations are subject to change by vendors without notice. I would appreciate any direct input, preferably first hand, from implementors.
どんな数値課題や機能操作もベンダーによって予告なしで変化を被りやすいです。 望ましくは、作成者から直のダイレクト入力をお願いします。
1.2. Presentation
1.2. プレゼンテーション
Without any easy organization for the material, information is arranged in a simple taxonomy from bottom-up complexity:
材料のための少しも簡単な組織がなければ、情報はボトムアップの複雑さから簡単な分類学でアレンジされます:
- Attribute Usage
- 属性用法
- Attribute Data Types
- 属性データ型
- Message Codes
- メッセージコード
- New Operations
- 新しい操作
2. Attribute Usage
2. 属性用法
The RADIUS RFCs define attribute type ranges and specific attribute definitions.
RADIUS RFCsは属性タイプ範囲と特定の属性定義を定義します。
- There are about 70 defined RADIUS attributes:
- およそ70の定義されたRADIUS属性があります:
- Values 192-223 are reserved for experimental use
- 値192-223は実験用のために予約されます。
- Values 224-240 are reserved for implementation-specific use
- 値224-240は実装特定的用法のために予約されます。
- Values 241-255 are reserved and should not be used.
- 値241-255を予約されていて、使用するべきではありません。
Mitton Informational [Page 3] RFC 2882 Extended RADIUS Practices July 2000
ミットン情報[3ページ]のRFC2882は2000年7月に半径習慣を表しました。
Attribute 26 was defined to be the Vendor Specific Attribute (VSA) with further internal structure to allow vendor expansion.
属性26は、ベンダー拡張を許すさらなる内部の構造があるVendor Specific Attribute(VSA)になるように定義されました。
2.1. Attribute conflicts
2.1. 属性闘争
In practice attributes 92-255 are in use by a vendor. And another vendor also use attributes in the 90-104 range and conflicts with this usage.
実際には、属性92-255はベンダーで使用中です。 そして、また、別のベンダーはこの用法との90-104範囲と闘争に属性を使用します。
To deal with these issues, server vendors have added vendor specific parameters to their client database files. The administrator has to indicate the vendor type of NAS along with the client IP address and secret, so that the server can disambiguate the attribute usage.
これらの問題に対処するために、サーバベンダーはベンダーの特定のパラメタをそれらのクライアントデータベース・ファイルに追加しました。 管理者はクライアントIPアドレスと秘密に伴うNASのベンダータイプを示さなければなりません、サーバが属性用法のあいまいさを除くことができるように。
One server has a single large vendors file to describe the mapping all attributes to an internal format that retains the vendor id. Another server implementation uses multiple dictionaries, each indexed to a NAS and Vendor Model definition list.
あるサーバで、a単一の大きいベンダーは、すべてがベンダーイドを保有する内部の形式の結果と考えるマッピングについて説明するためにファイルされます。 NASに索引をつけられたそれぞれとVendor Model定義は、別のサーバ実装が複数の辞書を使用すると記載します。
2.2. Attribute Value Conflicts
2.2. 属性値闘争
Adding additional attributes may be more trouble than necessary for simple features. Often existing RADIUS attributes could be extended with additional values (particularly attributes that are enumerated choices). But in doing such there is no way to guarantee not conflicting with other vendor's extensions.
追加属性を加えるのは、簡単な特徴に必要とするより多くの問題であるかもしれません。 しばしば既存のRADIUS属性は加算値(特に列挙された選択である属性)で広げられるかもしれません。 しかし、そのようなものをするのにおいて、他のベンダーの拡大との闘争でないのを保証する方法が全くありません。
2.2.1. Vendor Specific Enumerations proposal
2.2.1. ベンダーSpecific Enumerations提案
One proposed solution to this problem was Vendor Specific Enumerations (VSEs). That is to imbed the vendor's management ID in the numeric value (ala VSAs) which would to divide up the attribute value space. This technique has not seen any acceptance by the working group or other vendors, however, the vendor did accomplish the goal of not conflicting with working group additions or other vendor values.
この問題への1つの提案された解決がVendor Specific Enumerations(VSEs)でした。 それは、属性値スペースに分割するためにそうする数値(ala VSAs)におけるベンダーの管理IDを埋め込むことになっています。 このテクニックはワーキンググループか他のベンダーによる少しの承認も見ていなくて、しかしながら、ベンダーはワーキンググループ追加か他のベンダー値と衝突しないという目標を達成しました。
Example dictionary of VSE values:
VSE値の例の辞書:
VALUE Service-Type VSE-Authorize-Only 0x06300001
サービスタイプを評価してください、VSEが認可する、唯一、0×06300001
VALUE Acct-Status-Type VSE-User-Reject 0x06300001 VALUE Acct-Status-Type VSE-Call-Reject 0x06300002 VALUE Acct-Status-Type VSE-IPCP-Start 0x06300003 VALUE Acct-Status-Type VSE-IPXCP-Start 0x06300004 VALUE Acct-Status-Type VSE-ATCP-Start 0x06300005 VALUE Acct-Status-Type VSE-Accounting-Restart 0x06300006 VALUE Acct-Status-Type VSE-Accounting-Shutoff 0x06300007
VSE会計再開0×06300006が評価するVSE-IPXCP-スタート0×06300004が評価するVSE呼び出し廃棄物0×06300002が評価するAcct状態タイプVSEユーザ廃棄物0×06300001値のAcct状態タイプAcct状態タイプVSE-IPCP-スタート0×06300003値のAcct状態タイプAcct状態タイプVSE-ATCP-スタート0×06300005値のAcct状態タイプAcct状態タイプVSE会計遮断0×06300007を評価してください。
Mitton Informational [Page 4] RFC 2882 Extended RADIUS Practices July 2000
ミットン情報[4ページ]のRFC2882は2000年7月に半径習慣を表しました。
VALUE Acct-Status-Type VSE-Tunnel-Start 0x06300008 VALUE Acct-Status-Type VSE-Tunnel-Stop 0x06300009 VALUE Acct-Status-Type VSE-Tunnel-Reject 0x0630000a VALUE Acct-Status-Type VSE-Tunnel-Link-Start 0x0630000b VALUE Acct-Status-Type VSE-Tunnel-Link-Stop 0x0630000c VALUE Acct-Status-Type VSE-MP-Start 0x0630000d VALUE Acct-Status-Type VSE-MP-Stop 0x0630000e VALUE Acct-Status-Type VSE-Line-Seizure 0x0630000f VALUE Acct-Status-Type VSE-Rlogin-Start 0x06300010 VALUE Acct-Status-Type VSE-Rlogin-Stop 0x06300011
VSE mpが始まっている0×06300009のVSE mpが止まっている0x0630000e値のAcct状態値のAcct状態タイプVSEトンネル廃棄物0x0630000a値のAcct状態タイプVSEトンネルリンクスタート0x0630000b値のAcct状態タイプVSEトンネルリンク停止0x0630000c値のAcct状態タイプ0x0630000d値のAcct状態タイプタイプVSE線捕獲0x0630000fが評価する0×06300008値のAcct状態タイプVSEトンネル停止Acct状態タイプVSE-Rlogin-スタート0×06300010が評価する値のAcct状態タイプVSEトンネルスタートAcct状態タイプVSE-Rlogin-停止0×06300011
2.3. Vendor Specific Attribute Usage
2.3. ベンダーの特定の属性用法
Because attribute 26 Vendor Specific Attributes (VSAs) came late in the RADIUS working group development, there were some server implementations that were late to support them. Today, there are several leading implementations of clients that make extensive use of VSAs. What's unfortunate is that there is also several different formats of VSAs implemented. This is because the RFC suggested format does not support more than 256 attributes.
属性26Vendor Specific Attributes(VSAs)が遅くRADIUSワーキンググループ開発に入ったので、それらをサポートするのが遅れていたいくつかのサーバ実装がありました。 今日、VSAsの大規模な使用をするクライアントのいくつかの主な実装があります。 不幸なことはまた、実装されたVSAsのいくつかの異なった形式があるということです。 これはRFCが、形式が256以上の属性をサポートしないのを示したからです。
2.3.1. VSAs in use by some clients:
2.3.1. 何人かのクライアントで使用中のVSAs:
At the time this document was written, the following had be observed:
このドキュメントが書かれたとき、以下は観測されていました:
- Microsoft: several for MS-CHAP authentication support [9]
- マイクロソフト: さん-CHAP認証サポートのための数個[9]
- ACC: 42 [10]
- ACC: 42 [10]
- Nortel(Bay): about 60 VSAs and 16 VSEs
- ノーテル(湾): およそ60VSAsと16VSEs
- Nortel(Aptis): about 60 VSA: 20 1-byte, ~130 4-byte header.
Aptis VSAs have shifted from a regular format to a 4-byte header
format, due to the large number of attributes implemented.
- ノーテル(Aptis): およそ60VSA: 20 1バイト、~130 4バイトのヘッダー。 Aptis VSAsは通常の形式から4バイトのヘッダー形式に移行しました、実装された多くの属性のため。
- 3Com (USR): about 130
USR VSAs are different than the format suggested in RFC 2138.
They have a 4 byte type field and have no internal length.
- 3Com(USR): およそ130USR VSAsが書式がRFC2138に示されたより異なっています。 彼らは、4バイトのタイプ分野を持っていて、どんな内部の長さも持っていません。
Some vendors that did not initially use VSAs, have shifted in later releases VSA usage as a configuration option.
初めはないときにしたベンダーの中にはVSAsを使用して、設定オプションとして後のリリースVSA用法で移行したものもありました。
2.3.2. Clients that support Multiple Vendor Attributes
2.3.2. Multiple Vendor Attributesをサポートするクライアント
Now that MS-CHAP RADIUS attributes have been published in RFC 2548 [9] as Microsoft VSA attributes, it will become typical that for NAS clients that support MS-CHAP authentication to process several
さん-CHAP RADIUS属性がマイクロソフトVSA属性としてRFC2548[9]で発行されたので、NASクライアントに関して、それが数個を処理するためにさん-CHAP認証をサポートするのは典型的になるでしょう。
Mitton Informational [Page 5] RFC 2882 Extended RADIUS Practices July 2000
ミットン情報[5ページ]のRFC2882は2000年7月に半径習慣を表しました。
different vendor VSA types. This has implications for RADIUS servers that filter or "prune" return attributes based on the vendor make/model of the NAS client.
異なったベンダーVSAはタイプします。 これには、ベンダーに基づいたフィルタか「プルーン」リターン属性が作るか、またはモデル化するNASクライアントのRADIUSサーバのための意味があります。
One NAS implementation can receive up to three different vendor specific attribute sets, but will only send attributes according to the "mode" that has been configured by the operator. This allows it to fit into environments where the customer has become dependent on a particular set of RADIUS attributes, and allows the NAS to "drop-in" without server attribute changes.
1つのNAS実装が、最大3つの異なったベンダー特定の属性セットを受けることができますが、オペレータによって構成された「モード」に応じて、属性を送るだけでしょう。 これで、それは顧客が、特定のセットのRADIUS属性に依存するようになって、NASがサーバ属性変化なしで「ちょっと立ち寄ること」を許すところに環境に収まることができます。
There is another NAS that supports 3 vendor attributes sets concurrently. That is, it will normally use a combination of different vendor VSAs in return profiles from the server. This was done to support a superset of competing vendor's extensions, as well as it's own, and include an extensions from a sister product.
同時に3ベンダーが属性セットであるとサポートする別のNASがあります。 通常、すなわち、それはサーバからのリターンプロフィールの異なったベンダーVSAsの組み合わせを使用するでしょう。ベンダーのそれが自己であるのと同じくらい良い拡大を競争するスーパーセットにサポートして、姉妹製品からの拡大を含めるためにこれをしました。
3. Attribute Data Types
3. 属性データ型
The base RFCs define only has 4 basic data types:
RFCsが定義するベースは4つの基本のデータ型しか持っていません:
- integer, 32 bit unsigned
- 整数で、32ビット未署名です。
- string, 1-253 bytes, counted.
- ストリング(1-253バイト)は重要でした。
- ipaddr, 32 bit IPv4
- ipaddr、32ビットのIPv4
- date, 32 bit Unix format.
- 日付、32ビットのUnix形式。
Since then, various variations have been added:
それ以来、様々な変化は加えられます:
The tunnel authentication document [6] adds an optional compound "tag" byte to tunnel attributes. These are a single byte prepended to the data field in order to support sets of attributes to be returned. The byte value must be in the range 01-3F hex or it is considered to be data.
トンネル認証ドキュメント[6]は任意の合成「タグ」バイトをトンネル属性に加えます。 これらは、返される属性のセットを支えるデータ・フィールドにprependedされた1バイトです。 範囲01-3F十六進法にはバイト値があるに違いありませんか、またはデータであることは考えられます。
Note that there is no native support for IPv6 addresses. In fact IPv6 support is missing in some fixed message components too.
IPv6アドレスのどんなネイティブのサポートもないことに注意してください。 事実上、IPv6サポートはいくつかの固定メッセージコンポーネントでもなくなっています。
There have been special attribute types created within servers. For packet filters, the format called "abinary" was created. The user enters an ASCII string filter description in the user profile, but the server parses it into a binary string before passing it to the NAS. This lowers the complexity of the NAS parser. Also a "phonestring" server data type allows additional data type checking at the entry application.
サーバの中で創造された特別な属性タイプがいました。 パケットフィルタに関しては、"abinary"と呼ばれる形式は作成されました。 ユーザはASCIIストリングフィルタ記述をユーザ・プロファイルに入れますが、それをNASに通過する前に、サーバは2進のストリングにそれを分析します。 これはNASパーサの複雑さを下げます。 また、「phonestring」サーバデータ型はエントリーアプリケーションのときにチェックする追加データ型を許容します。
Mitton Informational [Page 6] RFC 2882 Extended RADIUS Practices July 2000
ミットン情報[6ページ]のRFC2882は2000年7月に半径習慣を表しました。
4. New Messages
4. 新しいメッセージ
A number of new message types have been introduced by various parties over time. The base specification has 6, vendors have added 26.
多くの新しいメッセージタイプが時間がたつにつれて、様々なパーティーによって導入されました。 基礎仕様には、6があって、ベンダーは26を加えました。
These fall into a number of categories which are described in the next section below. Some of these messages are actually used between the RADIUS server and some other resource server, using a RADIUS-like protocol to implement new functions.
これらは下の次のセクションで説明される多くのカテゴリになります。 これらのメッセージのいくつかが実際にRADIUSサーバとある他のリソースサーバの間で使用されます、新しい機能を実装するのにRADIUSのようなプロトコルを使用して。
6 Accounting Status
(now Interim Accounting [5])
7 Password Request
8 Password Ack
9 Password Reject
10 Accounting Message
6会計状態、(現在当座の会計[5])7パスワード要求8パスワードAck9パスワード廃棄物10会計メッセージ
21 Resource Free Request
22 Resource Free Response
23 Resource Query Request
24 Resource Query Response
25 Alternate Resource Reclaim Request
26 NAS Reboot Request
27 NAS Reboot Response
21 リソースの無料の要求22のリソースの無料の応答23リソース質問要求24リソース質問応答25の代替のリソースは要求26NASリブート要求27NASリブート応答を取り戻します。
29 Next Passcode
30 New Pin
31 Terminate Session
32 Password Expired
33 Event Request
34 Event Response
40 Disconnect Request
41 Disconnect Ack
42 Disconnect Nak
43 Change Filters Request
44 Change Filters Ack
45 Change Filters Nak
50 IP Address Allocate
51 IP Address Release
29 次のPasscode30の新しいピン31は分離Ack42が要求44変化がフィルターにかけるNak43変化フィルタにAck45変化から切断するというイベント応答40分離要求41がNak50IPアドレスをフィルターにかけるというパスワード失効33イベント要求34が51IPアドレスにリリースを割り当てるセッション32を終えます。
5. Additional Functions
5. 追加機能
These are operations performed using RADIUS extensions and additional messages types.
これらはRADIUS拡張子と追加メッセージタイプを使用することで実行された操作です。
Mitton Informational [Page 7] RFC 2882 Extended RADIUS Practices July 2000
ミットン情報[7ページ]のRFC2882は2000年7月に半径習慣を表しました。
5.1. Password Change
5.1. パスワード変化
Remotely requested password change operations were described and proposed, but rejected by the working group. None the less, the feature is still deployed in a number of products.
離れて要求されたパスワード変化操作は、ワーキンググループによって説明されて、提案されましたが、拒絶されました。 やはり、特徴は多くの製品の中にまだ配布されています。
Message types:
メッセージタイプ:
- Password Request
- Password Ack or Reject
- パスワード要求--パスワードAckか廃棄物
5.2. Authentication Modes
5.2. 認証モード
Additional message types have been added to negotiate passcode changes for token card servers.
追加メッセージタイプは、トークン・カードサーバのためにpasscode変化を交渉するために加えられます。
- Next Passcode
- New PIN
- Password Expired
- 次のPasscode--新しい暗証番号--パスワード失効
They allow the NAS or RADIUS server negotiate passcode changes with an external security server.
彼らがNASを許すか、またはRADIUSサーバは対外安全保障サーバとpasscode変化を交渉します。
5.3. Menus
5.3. メニュー
At least two vendors have built menuing interaction systems for use with terminal dial-ins.
少なくとも2つのベンダーが、端末のダイヤルインチで使用の相互作用システムをmenuingしながら、建てられました。
One implementation uses the Reply-Message string as the menu text to be displayed, and the State attribute to keep track of the place in the menu. The menu is displayed using the Access-Challenge message. The response is encoded in the User-Password field like an ordinary challenge sequence would.
1つの実装が、メニューの場所の動向をおさえるのに表示されるべきメニューテキスト、および州属性としてReply-メッセージストリングを使用します。 Access-挑戦メッセージを使用することでメニューを表示します。 応答は系列がそうする普通の挑戦のようにUser-パスワード欄でコード化されます。
Some RADIUS clients have problems with this because they cannot handle long or multiple Reply-Message attributes that may have embedded carriage returns and line-feeds. The new Echo attribute should also control echo behavior on the menu response. Use of the State attribute to keep track of a Challenge sequence is also standard behavior.
RADIUSクライアントの中にはそれらが復帰と改行を埋め込んだかもしれない長いか複数のReply-メッセージ属性を扱うことができないのでこれに関する問題を持っている人もいます。 また、新しいEcho属性はメニュー応答のときにエコーの振舞いを制御するべきです。 また、Challenge系列の動向をおさえる州属性の使用は標準の振舞いです。
Another implementation uses two vendor attributes (VSA-Menu-Item, and VSA-Menu-Selector as well as VSA-Third-Prompt) to convey this information. This implementation is vendor specific.
別の実装は、この情報を伝えるのに、2つのベンダー属性(VSAメニューの品目、およびVSA第3プロンプトと同様にVSAメニューセレクタ)を使用します。 この実装はベンダー特有です。
Mitton Informational [Page 8] RFC 2882 Extended RADIUS Practices July 2000
ミットン情報[8ページ]のRFC2882は2000年7月に半径習慣を表しました。
5.4. Pseudo Users
5.4. 疑似ユーザ
One client implementation takes advantage of your vanilla RADIUS server's ability to be used as a remote database server. By using some well-known, implementation specific, strings for Username and Password attributes, the NAS can request information from the server, such as: Static IP routes, Static IPX routes, or the Message of the Day.
1つのクライアント実装があなたのバニラRADIUSサーバのいくつかを使用することによってよく知られる実装特有のリモートデータベースサーバがUsernameとPasswordのために属性を結ぶので使用されるべき能力を利用して、NASはサーバからの以下の情報を要求できます。 デーの静的なIPルート、Static IPXルート、またはMessage。
These are called pseudo-user requests, because they use a user entry with this manufactured name, for purposes other than authentication.
認証以外の目的にこの製造名前によるユーザエントリーを使用するので、これらは疑似ユーザ要求と呼ばれます。
Another client also uses a pseudo-user technique for resolving unknown Filter-ID(11) values. An Access-Request message is sent to the RADIUS server with the Filter-ID as the Username value, the password is a known string, and the Service-Type is VSE- Authorization-Only. The response must also be of the same Service- Type, or the response will be ignored. The responding profile should contain the IP-Filter VSA attributes that will define the desired filter.
また、別のクライアントは、未知のFilter ID(11)値を決議するのに疑似ユーザのテクニックを使用します。 Usernameが評価するようにFilter-IDがあるRADIUSサーバにAccess-要求メッセージを送ります、そして、パスワードは知られているストリングです、そして、Service-タイプはVSE承認専用です。 また、同じServiceタイプには応答があるに違いありませんか、または応答は無視されるでしょう。 応じるプロフィールは必要なフィルタを定義するIP-フィルタVSA属性を含むはずです。
It should be noticed that pseudo-user profiles could be a security problem if a specific or operationally invalid Service-Type is not attached to the profile. The client should test for this returned value, to prevent normal dial-in users from gaining access via this profile.
特定の、または、操作上無効のService-タイプがプロフィールに付けられないなら疑似ユーザ・プロファイルが警備上の問題であるかもしれないのに気付かれるべきです。 クライアントは、普通のダイヤルインのユーザがこのプロフィールを通してアクセスを得るのを防ぐためにこの戻り値がないかどうかテストするべきです。
6. Resource Management
6. 資源管理
Authorized sessions may need to be allocated additional dynamic resources in order to perform their services. The most typical is IP addresses. The allocation may want to be delayed until needed or coordinated on a scale independent of the RADIUS server. Additional messages may be used to allocate and free these resources. The RADIUS server may proxy these requests to another server.
認可されたセッションは、追加ダイナミックなリソースが彼らのサービスを実行するために割り当てられる必要があるかもしれません。 最も典型的であるのは、IPアドレスです。 配分はRADIUSサーバの如何にかかわらずスケールで必要である、または調整されるまで遅れたいかもしれません。追加メッセージは、これらのリソースを割り当てて、解放するのに使用されるかもしれません。 RADIUSサーバはこれらが別のサーバに要求するプロキシがそうするかもしれません。
Examples: Certain servers can allocate addresses local to the NAS or use an outboard address server. Other servers have an internal address pool capability, which will fill in the Framed-IP-Address attribute with an assigned value based on pool selected.
例: あるサーバは、NASへのローカルのアドレスを割り当てるか、または船外のアドレスサーバを使用できます。他のサーバには、内部のアドレスプール能力があります。(割り当てられた値がプールに基づいて選択されている状態で、それは、Framed IPアドレス属性に記入するでしょう)。
6.1. Managed Resources:
6.1. 管理資源:
Resources managed include: IP Addresses, Concurrent Logins, Dial-in Port allocation policies, Tunnel limits and load distribution.
管理されたリソースは: IP Addresses、Concurrent Logins、中のDial Port配分方針、Tunnel限界、および負荷分配。
Mitton Informational [Page 9] RFC 2882 Extended RADIUS Practices July 2000
ミットン情報[9ページ]のRFC2882は2000年7月に半径習慣を表しました。
There are several different types of implementation techniques:
いくつかの異なったタイプの実装のテクニックがあります:
- Explicit request/free resource requests
- Monitor usage with deamons watching the state
- Explicit messages to a state deamon
- Monitor Accounting messages for state changes
- 明白な要求/無料の資源要求--deamonsが、州(州のdeamonへの明白なメッセージ)が状態へのAccountingメッセージをモニターするのを見ているモニター用法は変化します。
6.2. Resource Management Messages
6.2. 資源管理メッセージ
Messages used for resource management
資源管理に使用されるメッセージ
- IP Address Allocate
- IP Address Release
- アドレスが割り当てるIP--IPアドレスリリース
- Resource Request
- Resource Response
- Resource Free Request
- Resource Free Response
- Resource Reclaim Request
- NAS Reboot Request/Response
- 資源要求--リソース応答--リソースの無料の要求--リソースの無料の応答--リソースは要求を取り戻します--NASは要求/応答をリブートします。
These messages are used to allocate and free resources for a NAS from a centralized server. These mechanisms allows the service provider better administrative control than some automated LAN services, which don't have policy inputs or controls.
これらのメッセージは、集結されたサーバからNASのためのリソースを割り当てて、解放するのに使用されます。これらのメカニズムは方針入力かコントロールを持っていないいくつかの自動化されたLANサービスより良いサービスプロバイダー運営管理コントロールを許容します。
6.3. Concurrent Logins
6.3. 同時発生のログイン
The RADIUS protocol was designed to allow stateless servers. That is, servers that don't know the status of the active sessions. However, it is very important for many service providers to keep track of how many sessions a given user may have open, and accordingly disallow access.
RADIUSプロトコルは、状態がないサーバを許容するように設計されました。 すなわち、活発なセッションの状態を知らないサーバ。 しかしながら、多くに、維持するサービスプロバイダーが、与えられたユーザがいくつのセッションに戸外を持って、それに従って、アクセサリーを禁じるかもしれないかを追跡するのは、非常に重要です。
There are several different techniques used to implement login limits on a RADIUS environment. Some vendors have build NAS monitoring tools either into their RADIUS servers, either directly or as auxiliary deamons, that can check the session status of the controlled NASes by SNMP or proprietary methods.
ログイン限界を実装するのに使用されるいくつかの異なったテクニックがRADIUS環境にあります。 ベンダーにはある或るものは直接かそれらのRADIUSサーバか、補助のdeamonsとしたSNMPか独占メソッドで制御NASesのセッション状態をチェックできるモニターしているツールをNASに築き上げます。
Other vendors monitor the RADIUS accesses and accounting messages and derive state information from the requests. This monitoring is not as reliable as directly auditing the NAS, but it is also less vendor specific, and can work with any RADIUS NAS, provided it sends both streams to the same server.
他のベンダーが、RADIUSアクセスと会計メッセージをモニターして、州の情報に要求に由来しています。 このモニターが同じくらい直接NASを監査しながら信頼できませんが、また、より少ないベンダー特有であり、どんなRADIUS NASと共にも働くことができます、両方のストリームを同じサーバに送るなら。
Some of the approaches used:
アプローチのいくつかが使用しました:
Mitton Informational [Page 10] RFC 2882 Extended RADIUS Practices July 2000
ミットン情報[10ページ]のRFC2882は2000年7月に半径習慣を表しました。
- SNMP commands
- Telnet monitor deamon
- Accounting monitor
- SNMPコマンド--telnetモニターdeamon--会計モニター
6.4. Authorization Changes:
6.4. 承認変化:
To implement an active changes to a running session, such as filter changes or timeout and disconnect, at least one vendor has added a RADIUS "server" to his NAS. This server accepts messages sent from an application in the network, and upon matching some session information, will perform such operations.
実行しているセッションへのフィルタ交換かタイムアウトなどのアクティブな変化を実装して、切断するために、少なくとも1つのベンダーがRADIUS「サーバ」を彼のNASに加えました。 このサーバはアプリケーションからネットワークで送られたメッセージを受け入れます、そして、何らかのセッション情報を合わせるのに、そのような操作を実行するでしょう。
Messages sent from Server to NAS
ServerからNASに送られたメッセージ
- Change Filter Request
- Change Filter Ack / Nak
- Disconnect Request
- Disconnect Response
- フィルタ要求を変えてください--フィルタAck / Nakを変えてください--要求から切断してください--応答から切断してください。
Filters are used to limit the access the user has to the network by restricting the systems and protocols he can send packets to. Upon fulfilling some registration with an authorization server, the service provider may wish to remove those restrictions, or disconnect the user.
フィルタは、彼がパケットを送ることができるシステムとプロトコルを制限することによってユーザが持っているアクセスをネットワークに制限するのに使用されます。 承認サーバで何らかの登録を実現させると、サービスプロバイダーは、それらの制限を取り除くことを願っているか、またはユーザから切断するかもしれません。
7. Policy Services
7. 方針サービス
Some vendors have implemented policy servers using RADIUS as the control protocol. Two prominent Policy Managers act as RADIUS proxy filters and use RADIUS messages to deny access to new sessions that exceed active policy limits.
ベンダーの中には制御プロトコルとしてRADIUSを使用することで方針サーバを実装したものもありました。 2人の著名なPolicyマネージャが、RADIUSプロキシがフィルターにかけるように行動して、積極方針限界を超えている新しいセッションへのアクセスを拒絶するRADIUSメッセージを使用します。
One implementation behaves like a RADIUS proxy server, but with a policy process governing it's forward decisions. Typically a pre- authentication message (like the new RADIUS draft Service-Type = CallCheck) is emitted by the NAS upon call arrival. This message will contain only the Dialed-Number information in the Username field. The server receives the Access-Request messages and processes them against it's knowledge of the network state and the provisioned policies.
1つの実装がRADIUSプロキシサーバのように振る舞いますが、それは方針プロセスが治められている、前進の決定です。 通常、プレ認証メッセージ(新しいRADIUS草稿Service-タイプがCallCheckと等しいように)は呼び出し到着でのNASによって放たれています。 このメッセージはUsername分野にDialed-数の情報だけを保管するでしょう。 サーバは、Access-要求メッセージを受け取って、ネットワーク状態と食糧を供給された方針に関するそれの知識に対してそれらを処理します。
An Access-Accept will be returned to the system to accept the call, and many also contain dynamic policy information and Virtual POP specific default parameters. When the real PPP authentication is engaged, the proxy will forwards the Access-Request to a RADIUS server, if this session was approved at pre-auth. It can also process Access-Requests that were not preceded by a pre-auth exchange, and use the Username field for information about the
Access受け入れてください。呼び出しを受け入れるためにシステムに返されて、また、多くがダイナミックな方針情報とVirtualのPOPの特定のデフォルトパラメタを含んでいます。 本当のPPP認証が従事するとき、このセッションがプレauthで承認されたなら意志がRADIUSサーバへのAccess-要求を転送するプロキシです。 また、それはプレauth交換で先行されないで、情報にUsername分野を使用するAccess-要求を処理できます。
Mitton Informational [Page 11] RFC 2882 Extended RADIUS Practices July 2000
ミットン情報[11ページ]のRFC2882は2000年7月に半径習慣を表しました。
desired realm, in it's policy evaluation.
それの政策評価における必要な分野。
The other implementation performs a similar operations. It uses VSAs in the Access-Request to distinguish pre-authentication message types.
もう片方の実装は同様の操作を実行します。 それはプレ認証メッセージタイプを区別するというAccess-要求でVSAsを使用します。
8. Accounting Extensions
8. 会計拡大
Traditional Accounting only records session starts and stops which is pretty boring. Additional session information reporting can be added easily which gives a better picture of operation in use as they happen. Some event types are listed below.
唯一の記録セッションの伝統的なAccountingは始まって、止まります(かなり退屈です)。 容易に起こるとき使用中の操作の、より良い画像を与えた追加セッション情報報告は加えることができます。 イベントタイプの中には以下に記載されている人もいます。
8.1. Auditing/Activity
8.1. 監査/活動
- Call or Modem Starts, Stops
- Tunnel Starts, Stops
- Tunnel Link Starts & Stops
- Admin changes
- 呼び出しかModem Starts、Stops--トンネルStarts、Stops--トンネルLink Starts&Stops--アドミン変化
These events if monitored by a stateful server can be used to gather information about the usage of the network on a user/session basis. Information about when a particular user entered the network is more relevant to network service management than attempting track backwards from low level IP address flows. Useful information about port usage across a range of NASes allows service provider to quickly find problem areas or users.
statefulサーバによってモニターされるなら、ユーザ/セッションベースにネットワークの使用法に関して情報を収集するのにこれらのイベントを使用できます。 特定のユーザがネットワークに入った時に関する情報は低い平らなIPアドレス流れから道を後方に試みるよりネットワーク・サービス管理に関連しています。 さまざまなNASesの向こう側のポート用法に関する役に立つ情報で、サービスプロバイダーはすぐに問題領域かユーザを見つけることができます。
Information about call failures, successes, and quality are also deemed important many service providers.
また、呼び出し失敗、成功、および品質に関する情報は重要であると考えられます。多くのサービスプロバイダー。
Extending RADIUS accounting is easy, it's surprising that more implementations have not been made in this area.
RADIUS会計を広げるのが簡単である、より多くの実装がこの領域で作られていないのは、驚くべきものです。
9. Conclusions
9. 結論
In real life RADIUS Servers are becoming rather complex software implementations. They are often brokering authentication and authorization to other authorities or repositories. Variants of RADIUS protocol is often used as glue protocol for these type of solutions.
現実では、RADIUS Serversはかなり複雑なソフトウェア実行になっています。 彼らはしばしば他の当局か倉庫に認証と承認を仲介しています。 RADIUSプロトコルの異形はこれらのタイプの解決に接着剤プロトコルとしてしばしば使用されます。
Some of the solutions are kludges that could be cleaned up by better underlying services.
ソリューションのいくつかが、より良い基本的なサービスできれいにすることができるだろうクラッジです。
What this means to the implementor is that RADIUS as the RFCs describe it is becoming less relevant. Many additional features require matching client and server processing message processing.
これが作成者に意味することはRFCsがそれについて説明するときRADIUSが、より関連しないようになっているということです。 多くの付加的な機能が、クライアントとサーバ処理メッセージ処理に合っているのを必要とします。
Mitton Informational [Page 12] RFC 2882 Extended RADIUS Practices July 2000
ミットン情報[12ページ]のRFC2882は2000年7月に半径習慣を表しました。
Without standardization of these functions we don't have much interoperability in the field and much effort is spent in reverse engineering and reaction to unknown areas.
これらの機能の標準化がなければ、私たちはその分野に多くの相互運用性を持っていません、そして、多くの取り組みが未知の土地へのリバースエンジニアリングと反応に費やされます。
This memo is not a complete survey by any means. It is a representative summary of practices that I am aware of at the time of writing. I still appreciate input from vendors or users on practices and details known, and particularly any reference material you can pass me.
このメモは決して完成検査ではありません。 それは私がこれを書いている時点で意識している習慣の代表している概要です。 あなたが私を通過できる習慣、知られている詳細、および特にどんな参照資料でもベンダーかユーザからの入力に深く感謝致します。
10. Security Considerations
10. セキュリティ問題
This document documents known practices, and does not propose any particular new protocols. Extensions to RADIUS protocols create new security implications because of their functions go beyond those considered in the RFCs. Some of these include:
このドキュメントは、知られている習慣を記録して、どんな特定の新しいプロトコルも提案しません。 RADIUSプロトコルへの拡大はそれらの機能による含意がRFCsで考えられたものを超えて行かせる新しいセキュリティを作成します。 これらのいくつかは:
- The ability to change passwords via a RADIUS exchange was
deliberately left out of the protocol by the working group,
because of security concerns.
- The Pseudo-User profiles and the Call-Check operation may allow
unintended access if static and well-know account names and
passwords are allowed to be used by regular interactive accounts.
- Resource Management operations must be protected from denial of
service attacks.
- Client side authorization change exchanges need to be secured from
attacks that could disconnect or restrict user services.
- RADIUS交換でパスワードを変える能力は故意にワーキンググループによってプロトコルから外されました、安全上の配慮のために。 - Pseudo-ユーザ・プロファイルとCall-チェック操作は、静的であるなら故意でないアクセスを許して、アカウント名とパスワードが通常の対話的なアカウントで使用できるのをよく知るかもしれません。 - サービス不能攻撃からリソースManagement操作を保護しなければなりません。 - クライアントサイド承認変化交換は、ユーザサービスを切断する場合があったか、または制限する場合があった攻撃から機密保護される必要があります。
11. Implementation Documents
11. 実装ドキュメント
Information about the following implementations can be obtained from the respective owners. Most listed are available from the manufacturer's web site.
それぞれの所有者から以下の実装に関する情報を得ることができます。 記載された大部分はメーカーのウェブサイトから利用可能です。
11.1. Clients:
11.1. クライアント:
- 3Com(USR) Total Control Hub
- Ericsson(ACC) Tigris
draft-ilgun-radius-accvsa-01.txt, Dec 1998
- Lucent(Ascend) MAX TNT
- Lucent(Livingston) Portmaster
- Nortel(Aptis) CVX 1800
- Nortel(Bay Networks) Versalar 5399/8000 Remote Access Controller
- Intel(Shiva)
- 3Com(USR)の総Control Hub--1998年12月--(昇ります)透明なMAX TNT--透明な(リビングストン)Portmaster--ノーテル(Aptis)CVX1800--(ACC)チグリス草稿ilgun半径accvsa-01.txt、エリクソンノーテル(ベイネットワークス)Versalar5399/8000Remote Access Controller--インテル(シバ神)
Mitton Informational [Page 13] RFC 2882 Extended RADIUS Practices July 2000
ミットン情報[13ページ]のRFC2882は2000年7月に半径習慣を表しました。
11.2. Servers:
11.2. サーバ:
- Ericsson(ACC) Virtual Port Server Manager - Funk Steel-Belted RADIUS - Intel(Shiva) Access Manager - Lucent(Ascend) Access Control - Lucent(Ascend) NavisAccess - Lucent(Ascend) Modified Livingston 1.16 - Lucent(Livingston) V2.01 - Lucent(Livingston) ABM - Lucent Port Authority - MERIT AAA Servers - Nortel(Bay Networks) BaySecure Access Control - Nortel Preside Radius - Nortel CVX Policy Manager
- Ericsson(ACC) Virtual Port Server Manager - Funk Steel-Belted RADIUS - Intel(Shiva) Access Manager - Lucent(Ascend) Access Control - Lucent(Ascend) NavisAccess - Lucent(Ascend) Modified Livingston 1.16 - Lucent(Livingston) V2.01 - Lucent(Livingston) ABM - Lucent Port Authority - MERIT AAA Servers - Nortel(Bay Networks) BaySecure Access Control - Nortel Preside Radius - Nortel CVX Policy Manager
12. References
12. 参照
[1] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2138, April
1997.
[1]RigneyとC.とルーベンとA.とシンプソン、W.とS.ウィレンス、「ユーザサービス(半径)におけるリモート認証ダイヤル」RFC2138(1997年4月)。
[2] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
[2]Rigney、C.、「半径会計」、RFC2139、1997年4月。
[3] Rigney, C., Willens, S., Ruebens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000.
[3]RigneyとC.とウィレンスとS.とRuebens、A.とW.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」RFC2865(2000年6月)。
[4] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[4]Rigney、C.、「半径会計」、RFC2866、2000年6月。
[5] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC
2869, June 2000.
[5]RigneyとC.とWillatsとW.とP.カルフーン、「半径拡大」、RFC2869、2000年6月。
[6] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and
I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC
2868, June 2000.
[6]ゾルン、G.、ライファー、D.、ルーベン、A.、シュライバー、J.、Holdrege、M.、およびI.Goyret、「トンネルへの半径属性はサポートについて議定書の中で述べます」、RFC2868、2000年6月。
[7] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
[7] ゾルンとG.とAbobaとB.とD.ミットン、「トンネルプロトコルサポートのための半径会計変更」、RFC2867、2000年6月。
[8] Aboba, B. and G. Zorn, "Implementation of L2TP Compulsory
Tunneling via RADIUS", RFC 2809, April 2000.
[8]AbobaとB.とG.ゾルン、「RADIUSを通したL2TPコンパルソリーTunnelingの実装」、RFC2809、2000年4月。
[9] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC
2548, March 1999.
[9] ゾルン、G.、「マイクロソフトのベンダー特有の半径属性」、RFC2548、1999年3月。
[10] Ilgun, K., "RADIUS Vendor Specific Attributes for ACC/Ericsson
Datacom Access", Work in Progress.
[10] K.、「ACC/エリクソンのDatacomアクセスのための半径のベンダーの特定の属性」というIlgunは進行中で働いています。
Mitton Informational [Page 14] RFC 2882 Extended RADIUS Practices July 2000
ミットン情報[14ページ]のRFC2882は2000年7月に半径習慣を表しました。
13. Author's Address
13. 作者のアドレス
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
Mitton Informational [Page 15] RFC 2882 Extended RADIUS Practices July 2000
ミットン情報[15ページ]のRFC2882は2000年7月に半径習慣を表しました。
14. Full Copyright Statement
14. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 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機能のための基金は現在、インターネット協会によって提供されます。
Mitton Informational [Page 16]
ミットンInformationalです。[16ページ]
一覧
スポンサーリンク
