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.
著作権（C）インターネット協会（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.
このドキュメントでは、RADIUSのRFC 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年に結成された、およびダイヤルインターミナルサーバーの境界のセット内に収まるようにチャーターされました。残念ながら、ネットワークアクセスサーバー（NASの）の現実の世界は、小型でシンプルな滞在、と驚くほどの速度で進化し続けていません。
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のRFCは属性タイプの範囲および特定の属性の定義を定義します。
- 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が予約されており、使用してはならない値。
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.
追加の属性を追加すると、単純な機能のために必要以上に面倒かもしれません。多くの場合、既存のRADIUS属性は、追加の値（選択肢を列挙している、特に属性）を拡張することができます。しかし、このようなことで、他のベンダーの拡張と競合しませ保証する方法はありません。
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.
この問題の一つの提案された解決策は、ベンダー固有の列挙（VSEs）でした。これは、属性値空間を分割するでしょう（VSAをALA）の数値で、ベンダーの管理IDを埋め込むことです。この技法は、任意のワーキンググループによる受諾または他のベンダーを見ていない、しかし、ベンダーは、ワーキンググループの追加や他のベンダーの値と矛盾しないという目標を達成しました。
Example dictionary of VSE values:
VSE値の例辞書：
VALUE Service-Type VSE-Authorize-Only 0x06300001
VALUEサービスタイプVSE承認のみ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アカウンティング・ステータス・タイプVSE-ユーザー拒否0x06300001 VALUEのAcct-ステータス型VSE-コール拒否0x06300002 VALUEのAcct-ステータス型VSE-IPCPスタート0x06300003 VALUEのAcct-ステータス型VSE-IPXCPスタート0x06300004 VALUEアカウンティング-Status型VSE-ATCPスタート0x06300005 VALUEのAcct-ステータス型VSE-会計-再起動0x06300006 VALUEのAcct-ステータス型VSE-会計-締め切り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
VALUEアカウンティング・ステータス・タイプVSE-トンネルスタート0x06300008 VALUEのAcct-ステータス型VSE-トンネルストップ0x06300009 VALUEのAcct-ステータス型VSE-トンネル拒否0x0630000aのVALUEのAcct-ステータス型VSE-トンネルリンクスタート0x0630000b VALUEアカウンティング・ステータス・タイプVSE-トンネルリンク停止0x0630000c VALUEのAcct-ステータス型VSE-MP-スタート0x0630000d VALUEのAcct-ステータス型VSE-MP-ストップ0x0630000e VALUEのAcct-ステータス型VSE-ライン発作0x0630000f VALUEアカウンティング・ステータス・タイプVSE-rloginのスタート0x06300010 VALUEのAcct-ステータス型VSE-rloginのストップ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以上の属性をサポートしていないフォーマットを提案するためです。
At the time this document was written, the following had be observed:
この文書が書かれた時点で、次のことが観察されました：
- Microsoft: several for MS-CHAP authentication support [9]
- マイクロソフト：MS-CHAP認証をサポートするためのいくつかの[9]
- ACC: 42 [10]
- ACC：42 [10]
- Nortel(Bay): about 60 VSAs and 16 VSEs
- ノーテル（ベイ）：約60のVSAと16 VSEs
- 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）：約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の彼らは4バイトのタイプフィールドを有し、全く内部長さを有していないフォーマットは、RFC 2138で提案とは異なります。
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.
マイクロソフトVSA属性として今、MS-CHAPのRADIUS属性はRFC 2548で公開されていること[9]、それはいくつかの異なるベンダーのVSAタイプを処理するために、MS-CHAP認証をサポートするNASクライアントのために、典型的ななります。これは、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.
一つの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があります。つまり、通常はサーバーからの戻りプロファイルで異なるベンダーのVSAを組み合わせて使用する、です。これは、競合ベンダーの拡張のスーパーセットをサポートするために行われただけでなく、それが所有しています、そして姉妹品から機能拡張が含まれています。
The base RFCs define only has 4 basic data types:
ベースRFCはわずか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パーサの複雑性を低下させます。また、「phonestring」サーバーのデータ型は、入力アプリケーションでチェックする追加のデータ型を可能にします。
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
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
34のイベント応答40切断要求41を外したAck 42切断のNak 43変更フィルタ44の変更は、フィルタ要求30新しいPINが31セッション32パスワードを終了29次へパスコードは、33イベント要求を期限切れのAck 45変更のNak 50個のIPアドレスをフィルタ51個のIPアドレス解放を割り当て
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
- 次のパスコード - 新しいPIN - パスワードの有効期限が切れ
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.
少なくとも二つのベンダーは、端末のダイヤルインで使用するためのメニュー操作の対話システムを構築してきました。
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.
一つの実装では、メニュー内の場所を追跡するために、表示されるメニューのテキスト、およびState属性として返信メッセージ文字列を使用しています。メニューは、Access-Challengeメッセージを使用して表示されます。応答は、通常のチャレンジシーケンスのようにユーザーパスワード]フィールドになり符号化されています。
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クライアントは、これで問題があります。新しいエコー属性は、メニュー応答にエコー動作を制御しなければなりません。チャレンジシーケンスを追跡するState属性の使用は、標準的な動作です。
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-メニュー・セレクターだけでなく、VSA-サードプロンプト）を使用しています。この実装は、ベンダー固有のものです。
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.
一つのクライアントの実装では、リモート・データベース・サーバーとして使用するためにあなたのバニラRADIUSサーバの能力を活用しています。スタティックIPルート、スタティックIPXルート、または日のメッセージ：、ユーザー名とパスワード属性の文字列を特定のいくつかのよく知られている、実装を使用することにより、NASのような、サーバから情報を要求することができます。
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）の値を解決するための疑似ユーザー技術を使用します。 Access-Requestメッセージをフィルター-IDのユーザー名の値としてRADIUSサーバに送信され、パスワードが知られている文字列で、サービスタイプは、VSE-認証のみです。応答も同じサービスタイプのものでなければならない、または応答は無視されます。応答プロファイルは、所望のフィルタを定義するVSA属性IPフィルタを含める必要があります。
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サーバ5月プロキシ別のサーバにこれらの要求。
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-Address属性に入力されます内部アドレスプール機能を、持っています。
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アドレスが割り当て - 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.
RADIUS環境上のログイン制限を実装するために使用されるいくつかの異なる技術があります。一部のベンダーは、SNMPや独自の方法で制御のNASのセッションの状態を確認することができる、直接または補助のデーモンとして、どちらか彼らの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のモニタデーモンを - 会計モニター
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.
そのようなフィルタの変更またはタイムアウトおよび切断のような実行中のセッションへの活性変化を実現するために、少なくとも一つのベンダーが自分のNASにRADIUS「サーバ」を追加しました。このサーバは、ネットワーク内のアプリケーションから送信されたメッセージを受け取り、いくつかのセッション情報と一致すると、このような動作を実行します。
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を使用してポリシーサーバを実装しています。二つの著名なポリシーマネージャには、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.
一つの実装では、RADIUSプロキシサーバのように動作しますが、政策過程を支配してそれは前方の決定です。典型的には、（新しいRADIUSドラフトサービスタイプ= 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.
アクセス - 受け入れは、コールを受け入れるためにシステムに返され、その多くはまた、動的なポリシー情報と仮想POP特定のデフォルトパラメータが含まれています。実際のPPP認証が締結されている場合は、プロキシは、RADIUSサーバに転送アクセス要求し、このセッションは、事前認証で承認された場合。また、事前認証交換によって先行されなかったアクセス - 要求を処理し、それが政策評価だ中で、必要な領域については、[ユーザー名]フィールドを使用することができます。
The other implementation performs a similar operations. It uses VSAs in the Access-Request to distinguish pre-authentication message types.
他の実装では、同様の動作を行います。これは、事前認証メッセージの種類を区別するために、アクセス要求に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.
ステートフルサーバーで監視する場合、これらのイベントは、ユーザー/セッションベースでネットワークの使用状況に関する情報を収集するために使用することができます。特定のユーザがネットワークに入った時に関する情報は、低レベルのIPアドレスの流れから逆方向にトラックをしようとするよりも、ネットワークサービスの管理に、より関連性があります。 NASの範囲でポートの使用状況に関する有用な情報は、サービスプロバイダが、素早く問題領域やユーザーを見つけることができます。
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アカウンティングの拡張が容易で、それはより多くの実装がこの領域で行われていないことは驚くべきことです。
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サーバは、かなり複雑なソフトウェア実装になっています。彼らはしばしば他の当局やリポジトリへの認証と承認を仲介しています。 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.
RFCが、それはあまり関係になってきて説明するようにこれが実装に意味することは、そのRADIUSです。多くの追加機能は、一致するクライアントとサーバの処理メッセージ処理を必要とします。
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プロトコルの拡張は、RFCで考えられたものを超えたため、その機能の新しいセキュリティへの影響を作成します。これらのいくつかは、次のとおりです。
- 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サイトから入手できます。
- 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）トータルコントロールハブ - エリクソン（ACC）チグリスドラフトilgun半径-accvsa-01.txt、1998年12月 - ルーセント（昇順）MAX TNT - ルーセント（リビングストン）ポートメンテナー - ノーテル（Aptis）CVX 1800 - ノーテル（ベイネットワーク）Versalar 8000分の5399リモートアクセスコントローラ - インテル（シヴァ）
- 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）仮想ポートサーバーマネージャ - ファンクスチールベルト付きRADIUS - インテル（シヴァ）のAccess Manager - ルーセント（アセンド）アクセス制御 - ルーセント（アセンド）NavisAccess - ルーセント（アセンド）リビングストン1.16修正 - ルーセント（リビングストン）V2。 01 - ルーセント（リビングストン）ABM - ルーセント港湾局 - MERITのAAAサーバ - ノーテル（ベイネットワーク）BaySecureアクセス制御 - ノーテル主宰半径 - ノーテル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.、ルーベンス、A.、シンプソン、W.及びS. Willensを、 "リモート認証ダイヤルインユーザーサービス（RADIUS）で"、RFC 2138、1997年4月。
[2] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
[2] Rigney、C.、 "RADIUSアカウンティング"、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.およびW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）においてリモート認証ダイヤル"。
[4] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[4] Rigney、C.、 "RADIUSアカウンティング"、RFC 2866、2000年6月。
[5] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[5] Rigney、C.、Willats、W.およびP.カルフーン、 "RADIUS拡張機能"、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]ゾルン、G.、Leifer、D.、ルーベンス、A.、シュライバー、J.、ホールドレッジ、M.およびI. Goyretを、2000年6月、RFC 2868 "RADIUSは、トンネルプロトコルサポートのための属性"。
[7] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
[7]ソーン、G.、Aboba、B.とD.ミトン、 "トンネルプロトコルサポートのためのRADIUSアカウンティングの変更"、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.ゾルン、 "RADIUSを介してL2TP強制トンネリングの実装"、RFC 2809、2000年4月。
[9] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
[9]ツォルン、G.は、 "マイクロソフトのベンダー固有のRADIUSアトリビュート"、RFC 2548、1999年3月。
[10] Ilgun, K., "RADIUS Vendor Specific Attributes for ACC/Ericsson Datacom Access", Work in Progress.
[10] Ilgun、K.、 "ACC /エリクソンデータ通信アクセスするためのRADIUSベンダー固有属性"、ProgressのWork。
David Mitton Nortel Networks 880 Technology Park Drive Billerica, MA 01821
デヴィッド・ミトンNortel Networksの880テクノロジーパークドライブビレリカ、MA 01821
Phone: 978-288-4570 EMail: dmitton@nortelnetworks.com
電話：978-288-4570 Eメール：dmitton@nortelnetworks.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。