[要約] RFC 2882は、ネットワークアクセスサーバーの要件に関する拡張RADIUSプラクティスについてのガイドラインです。このRFCの目的は、ネットワークアクセスサーバーの設計と実装において、RADIUSプロトコルの拡張機能を提供することです。
Network Working Group D. Mitton
Request for Comments: 2882 Nortel Networks
Category: Informational July 2000
Network Access Servers Requirements: Extended RADIUS Practices
ネットワークアクセスサーバーの要件：拡張された半径プラクティス
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
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.
このドキュメントでは、半径RFCS 2138、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
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
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年に同じ名前のプロトコルを文書化するために設立され、ダイヤルインターミナルサーバーの境界のセット内にとどまるようにチャーターされました。残念ながら、ネットワークアクセスサーバー（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.
私は、業界のマニュアルを読むことからこれらの機能の詳細を知り、競争力のある入札仕様でそれらに応答する必要があることがよくあります。彼らがフィールドに展開されると、彼らは事実上の基準の力を集めます。
Because they have been done outside scope of the RFCs, they are vendor specific, and introduce significant problems in offering an interoperable product.
それらはRFCの範囲外で行われているため、ベンダー固有のものであり、相互運用可能な製品を提供する際に重大な問題を導入します。
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.
数値割り当てまたは機能操作は、予告なしにベンダーによって変更される場合があります。実装者からの直接的な入力、できればファーストハンドに感謝します。
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
- 新しい操作
The RADIUS RFCs define attribute type ranges and specific attribute definitions.
RADIUS RFCSは、属性タイプの範囲と特定の属性定義を定義します。
- There are about 70 defined RADIUS attributes:
- 約70の定義済み半径属性があります。
- 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は予約されており、使用しないでください。
Attribute 26 was defined to be the Vendor Specific Attribute (VSA) with further internal structure to allow vendor expansion.
属性26は、ベンダーの拡張を可能にするために、さらに内部構造を持つベンダー固有の属性（VSA）であると定義されました。
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.
1つのサーバーには、すべての属性をベンダーIDを保持する内部形式へのマッピングを記述する単一の大手ベンダーファイルがあります。別のサーバー実装では、それぞれがNASおよびベンダーモデルの定義リストにインデックスされた複数の辞書を使用します。
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.
追加の属性を追加することは、単純な機能に必要以上のトラブルになる可能性があります。多くの場合、既存の半径属性を追加の値（特に列挙された選択肢である属性）で拡張できます。しかし、そうすることで、他のベンダーの拡張と矛盾しないことを保証する方法はありません。
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つは、ベンダー固有の列挙（VSE）でした。つまり、属性値スペースを分割する数値（ALA VSA）にベンダーの管理IDを埋め込みます。この手法では、ワーキンググループや他のベンダーによる受け入れは見られませんでしたが、ベンダーはワーキンググループの追加や他のベンダーの価値と矛盾しないという目標を達成しました。
Example dictionary of VSE values:
VSE値の例の辞書：
VALUE Service-Type VSE-Authorize-Only 0x06300001
Value Service-Type VSE-Authorizeのみの0x06300001
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
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
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.
属性26のベンダー固有の属性（VSA）は、RADIUSワーキンググループの開発の後半に来たため、それらをサポートするのに遅れたサーバーの実装がいくつかありました。今日、VSAを広範囲に使用するクライアントの主要な実装がいくつかあります。残念ながら、VSAのいくつかの異なる形式が実装されていることもあります。これは、RFC提案形式が256を超える属性をサポートしていないためです。
2.3.1. VSAs in use by some clients:
2.3.1. 一部のクライアントが使用しているVSA：
At the time this document was written, the following had be observed:
この文書が書かれた時点で、以下が観察されていました。
- Microsoft: several for MS-CHAP authentication support [9]
- Microsoft：MS-Chap認証サポート用[9]
- ACC: 42 [10]
- ACC：42 [10]
- Nortel(Bay): about 60 VSAs and 16 VSEs
- Nortel（Bay）：約60個のVSAと16個のVSE
- 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.
- Nortel（Aptis）：約60 VSA：20 1バイト、〜130 4バイトヘッダー。APTIS VSAは、実装された多数の属性により、通常の形式から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）：約130のUSR VSAは、RFC 2138で提案されている形式とは異なります。4バイト型フィールドがあり、内部長がありません。
Some vendors that did not initially use VSAs, have shifted in later releases VSA usage as a configuration option.
最初にVSAを使用していなかった一部のベンダーは、構成オプションとしてVSAの使用を後のリリースでシフトしました。
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 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.
MS-Chap Radius属性がRFC 2548 [9]でMicrosoft VSA属性として公開された今、MS-Chap認証をサポートするNASクライアントにとって、いくつかの異なるベンダー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属性のセットに依存するようになった環境に適合し、Server属性の変更なしで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があります。つまり、通常、サーバーからの見返りに異なるベンダーVSAの組み合わせを使用します。これは、競合するベンダーの拡張機能のスーパーセットをサポートするために行われ、独自のベンダーの拡張機能と、姉妹製品からの拡張機能が含まれています。
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]は、オプションの化合物「タグ」バイトをトンネル属性に追加します。これらは、返される属性のセットをサポートするために、データフィールドに加えられた単一のバイトです。バイト値は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に渡します。これにより、NASパーサーの複雑さが低下します。また、「ポネストリング」サーバーデータ型を使用すると、エントリアプリケーションで追加のデータ型を確認できます。
A number of new message types have been introduced by various parties over time. The base specification has 6, vendors have added 26.
多くの新しいメッセージタイプが、時間の経過とともにさまざまな関係者によって導入されています。ベース仕様には6つのベンダーが追加されています。
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パスワードACK 9パスワード拒否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代替リソースリクエスト26 NASリブートリクエスト27 NASリブート応答
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 NEXT PASSCODE 30 NEW PIN 31 ERTERING SESSION 32パスワードの有効期限33イベントリクエスト34イベント応答40リクエスト41切断ACK 42切断NAK 43変更フィルターの変更
These are operations performed using RADIUS extensions and additional messages types.
これらは、RADIUS拡張機能と追加のメッセージタイプを使用して実行される操作です。
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または拒否
Additional message types have been added to negotiate passcode changes for token card servers.
トークンカードサーバーのパスコード変更をネゴシエートするために、追加のメッセージタイプが追加されました。
- Next Passcode - New PIN - Password Expired
- 次のパスコード - 新しいピン - パスワードの有効期限が切れます
They allow the NAS or RADIUS server negotiate passcode changes with an external security server.
これらは、NASまたはRADIUSサーバーが外部セキュリティサーバーでパスコードの変更をネゴシエートすることを可能にします。
At least two vendors have built menuing interaction systems for use with terminal dial-ins.
少なくとも2つのベンダーが、ターミナルのダイヤルインで使用するためのメニーイングインタラクションシステムを構築しています。
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-Message文字列を表示するように使用し、状態属性を使用してメニューの場所を追跡します。メニューは、アクセスチャレンジメッセージを使用して表示されます。応答は、通常のチャレンジシーケンスのようにユーザーパスワードフィールドにエンコードされます。
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クライアントは、キャリッジリターンとラインフィードが組み込まれている可能性のある長いまたは複数の応答メッセージ属性を処理できないため、これに問題があります。新しいエコー属性は、メニュー応答のエコー動作も制御する必要があります。チャレンジシーケンスを追跡するための状態属性の使用も標準的な動作です。
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-Menu-Item、およびVSA-Menu-Selector、およびVSA-Third-Prompt）を使用して、この情報を伝えます。この実装はベンダー固有です。
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サーバーがリモートデータベースサーバーとして使用する機能を活用しています。よく知られている実装固有のユーザー名とパスワード属性の文字列を使用することにより、NASは、静的IPルート、静的IPXルート、またはその日のメッセージなど、サーバーから情報を要求できます。
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.
また、別のクライアントは、不明なフィルターID（11）値を解決するために擬似ユーザー手法を使用しています。ユーザー名の値として、Filter-IDを使用してAccess-RequestメッセージがRADIUSサーバーに送信され、パスワードは既知の文字列であり、サービスタイプはVSE-Authorizationのみです。応答も同じサービスタイプでなければならないか、応答は無視されます。応答するプロファイルには、目的のフィルターを定義するIP-Filter 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.
特定のまたは操作的に無効なサービスタイプがプロファイルに添付されていない場合、擬似ユーザープロファイルがセキュリティの問題になる可能性があることに注意する必要があります。クライアントは、通常のダイヤルインユーザーがこのプロファイルを介してアクセスを獲得できないように、この返された値をテストする必要があります。
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にローカルなアドレスを割り当てるか、船外アドレスサーバーを使用できます。他のサーバーには内部アドレスプール機能があり、選択されたプールに基づいて割り当てられた値でフレーム付き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アドレス、同時ログイン、ダイヤルインポート割り当てポリシー、トンネル制限、負荷分布が含まれます。
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
- 明示的なリクエスト/無料リソースリクエスト - 州を監視する悪魔との使用の使用 - 状態デーモンへの明示的なメッセージ - 状態の変更のための会計メッセージを監視する
Messages used for resource management
リソース管理に使用されるメッセージ
- IP Address Allocate - IP Address Release
- IPアドレスALLOCATE -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サービスよりも優れた管理制御を可能にします。
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.
半径環境にログイン制限を実装するために使用されるいくつかの異なる手法があります。一部のベンダーは、SNMPまたは独自の方法で制御されたnaseのセッションステータスを確認できる直接または補助ディーモンとして、RADIUSサーバーに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:
使用されるアプローチのいくつか：
- SNMP commands - Telnet monitor deamon - Accounting monitor
- SNMPコマンド-Telnet Monitor Deamon -Accounting Monitor
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つのベンダーがNASに半径「サーバー」を追加しました。このサーバーは、ネットワーク内のアプリケーションから送信されたメッセージを受け入れ、セッション情報を一致させると、そのような操作が実行されます。
Messages sent from Server to NAS
サーバーから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.
フィルターは、パケットを送信できるシステムとプロトコルを制限することにより、ユーザーがネットワークに持っているアクセスを制限するために使用されます。承認サーバーで登録を履行すると、サービスプロバイダーはこれらの制限を削除するか、ユーザーを切断することを希望する場合があります。
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つの著名なポリシーマネージャーは、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-Type = CallCheckなど）は、呼び出し到着時にNASによって放出されます。このメッセージには、ユーザー名フィールドにダイヤル番号情報のみが含まれます。サーバーは、アクセス要求メッセージを受信し、ネットワーク状態とプロビジョニングされたポリシーに関する知識に対してそれらを処理します。
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 desired realm, in it's policy evaluation.
Access-Acceptがシステムに返され、コールを受け入れます。多くの人には、動的なポリシー情報と仮想POP固有のデフォルトパラメーターも含まれています。実際のPPP認証が関与すると、プロキシは、このセッションがPre-Authで承認された場合、Access-RequestをRADIUSサーバーに転送します。また、Auth Pre-Auth Exchangeが先行していなかったアクセス要求を処理し、ポリシー評価で目的の領域に関する情報のためにユーザー名フィールドを使用することもできます。
The other implementation performs a similar operations. It uses VSAs in the Access-Request to distinguish pre-authentication message types.
他の実装は、同様の操作を実行します。Access-RequestでVSAを使用して、認証前のメッセージタイプを区別します。
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.
従来の会計学のみのレコードセッションの開始と停止は、かなり退屈です。追加のセッション情報レポートを簡単に追加でき、使用中の操作のより良い画像を提供します。いくつかのイベントタイプを以下に示します。
- Call or Modem Starts, Stops - Tunnel Starts, Stops - Tunnel Link Starts & Stops - Admin changes
- 通話またはモデムの開始、停止 - トンネルの開始、停止 - トンネルリンクの開始と停止 - 管理者の変更
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アドレスフローから後方に追跡するよりも、ネットワークサービス管理に関連しています。さまざまなnaseにわたるポート使用に関する有用な情報により、サービスプロバイダーは問題領域またはユーザーをすばやく見つけることができます。
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.
半径の会計を拡張するのは簡単です。この分野でより多くの実装が行われていないことは驚くべきことです。
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サーバーはかなり複雑なソフトウェアの実装になりつつあります。彼らはしばしば他の当局またはリポジトリに認証と承認を仲介しています。半径プロトコルのバリエーションは、これらのタイプのソリューションの接着剤プロトコルとしてよく使用されます。
Some of the solutions are kludges that could be cleaned up by better underlying services.
いくつかのソリューションは、より良い基礎となるサービスによってクリーンアップできるKludgesです。
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.
これが実装者にとって意味することは、RFCが説明するように、それがそれほど関連性が低くなっていることです。多くの追加機能には、クライアントとサーバーの処理メッセージ処理を一致させる必要があります。
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.
このメモは、決して完全な調査ではありません。これは、執筆時点で私が知っている実践の代表的な要約です。既知の慣行と詳細、特にあなたが私に渡すことができるすべての参照資料について、ベンダーまたはユーザーからの意見に感謝します。
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交換を介してパスワードを変更する機能は、セキュリティ上の懸念のため、ワーキンググループによって意図的にプロトコルから除外されました。 - 擬似ユーザープロファイルとコールチェック操作により、静的およびよく知られているアカウント名とパスワードを通常のインタラクティブアカウントで使用できる場合、意図しないアクセスが可能になる場合があります。 - リソース管理操作は、サービス拒否攻撃から保護する必要があります。 - クライアント側の承認の変更交換は、ユーザーサービスを切断または制限する可能性のある攻撃から確保する必要があります。
Information about the following implementations can be obtained from the respective owners. Most listed are available from the manufacturer's web site.
次の実装に関する情報は、それぞれの所有者から入手できます。ほとんどのリストは、メーカーのWebサイトから入手できます。
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）Total Control Hub -Ericsson（ACC）Tigris Draft -Ilgun -Radius -ACCVSA -01.TXT、1998年12月 - Lucent（Ascend）Max TNT -Lucent（Livingston）Portmaster -Nortel（Aptis）CVX 1800 -Nortel（ベイネットワーク）Versalar 5399/8000リモートアクセスコントローラー-Intel（Shiva）
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
- エリクソン（ACC）仮想ポートサーバーマネージャー - ファンクスチールベルトラジアス - インテル（シヴァ）アクセスマネージャー-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 Prise Radius -Nortel CVXポリシーマネージャー
[1] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[1] Rigney、C.、Rubens、A.、Simpson、W。and S. Willens、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2138、1997年4月。
[2] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
[2] Rigney、C。、「Radius Accounting」、RFC 2139、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.、Willens、S.、Ruebens、A。and W. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[4] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[4] Rigney、C。、「Radius Accounting」、RFC 2866、2000年6月。
[5] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[5] Rigney、C.、Willats、W。and P. Calhoun、「Radius Extensions」、RFC 2869、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] Zorn、G.、Leifer、D.、Rubens、A.、Shriver、J.、Holdrege、M。、およびI. Goyret、「トンネルプロトコルサポートの半径属性」、RFC 2868、2000年6月。
[7] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
[7] Zorn、G.、Aboba、B。、およびD. Mitton、「トンネルプロトコルサポートのための半径会計変更」、RFC 2867、2000年6月。
[8] Aboba, B. and G. Zorn, "Implementation of L2TP Compulsory Tunneling via RADIUS", RFC 2809, April 2000.
[8] Aboba、B。およびG. Zorn、「RADIUSを介したL2TP強制トンネルの実装」、RFC 2809、2000年4月。
[9] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
[9] Zorn、G。、「Microsoft Vendor固有のRADIUS属性」、RFC 2548、1999年3月。
[10] Ilgun, K., "RADIUS Vendor Specific Attributes for ACC/Ericsson Datacom Access", Work in Progress.
[10] Ilgun、K。、「ACC/ERICSSON DATACOM ACCESSのRADIUSベンダー固有の属性」、進行中の作業。
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 (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。