[要約] RFC 2607は、ローミングにおけるプロキシチェーンとポリシーの実装に関するガイドラインです。このRFCの目的は、異なるネットワーク環境でのプロキシチェーンの設定とポリシーの実装を効果的に行うための手順を提供することです。
Network Working Group B. Aboba
Request for Comments: 2607 Microsoft Corporation
Category: Informational J. Vollbrecht
Merit Networks, Inc.
June 1999
Proxy Chaining and Policy Implementation in Roaming
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 (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document describes how proxy chaining and policy implementation can be supported in roaming systems. The mechanisms described in this document are in current use.
この文書では、プロキシチェーンとポリシーの実装はシステムをローミングでサポートする方法について説明します。この文書で説明するメカニズムは、現在使用されています。
However, as noted in the security considerations section, the techniques outlined in this document are vulnerable to attack from external parties as well as susceptible to fraud perpetrated by the roaming partners themselves. As a result, such methods are not suitable for wide-scale deployment on the Internet.
セキュリティの考慮事項の項で述べたようにしかし、この文書で概説技術は、ローミングパートナー自身で犯さ詐欺に外部の関係者だけでなく、影響を受けやすいから攻撃に脆弱です。その結果、このような方法は、インターネット上の大規模な展開には適していません。
This document frequently uses the following terms:
このドキュメントは頻繁に次の用語を使用しています：
Network Access Server The Network Access Server (NAS) is the device that clients contact in order to get access to the network.
ネットワークアクセスサーバー] [ネットワークアクセスサーバ（NAS）は、クライアントがネットワークへのアクセスを得るために連絡するデバイスです。
RADIUS server This is a server which provides for authentication/authorization via the protocol described in [3], and for accounting as described in [4].
このRADIUSサーバは、[3]、[4]に記載のように会計のために記載したプロトコルを介して認証/認可を提供するサーバです。
RADIUS proxy In order to provide for the routing of RADIUS authentication and accounting requests, a RADIUS proxy can be employed. To the NAS, the RADIUS proxy appears to act as a RADIUS server, and to the RADIUS server, the proxy appears to act as a RADIUS client.
RADIUS認証およびアカウンティング要求のルーティングを提供するためにRADIUSプロキシは、RADIUSプロキシを使用することができます。 NASに、RADIUSプロキシは、RADIUSサーバとして機能するように表示され、RADIUSサーバに、プロキシは、RADIUSクライアントとして動作するように表示されます。
Network Access Identifier In order to provide for the routing of RADIUS authentication and accounting requests, the userID field used in PPP (known as the Network Access Identifier or NAI) and in the subsequent RADIUS authentication and accounting requests, can contain structure. This structure provides a means by which the RADIUS proxy will locate the RADIUS server that is to receive the request. The NAI is defined in [6].
、RADIUS認証およびアカウンティング要求のルーティングを提供する（ネットワークアクセス識別子またはNAIとしても知られる）PPPで使用されるユーザIDフィールドと、その後のRADIUS認証およびアカウンティング要求に、構造を含有することができるために、ネットワークアクセス識別子。この構造は、RADIUSプロキシが要求を受信するRADIUSサーバを探しますする手段を提供します。 NAIは、[6]で定義されています。
Roaming relationships Roaming relationships include relationships between companies and ISPs, relationships among peer ISPs within a roaming association, and relationships between an ISP and a roaming consortia. Together, the set of relationships forming a path between a local ISP's authentication proxy and the home authentication server is known as the roaming relationship path.
関係ローミングローミング関係は、企業やISP、ローミング関連付け内のピアのISP間の関係、およびISPとローミングコンソーシアムとの間の関係の関係を含みます。一緒に、ローカルISPの認証プロキシとホーム認証サーバとの間の経路を形成する関係のセットは、ローミング関係パスとして知られています。
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [5].
この文書に記載されている、キーワード "MAY"、「MUST、 "MUST NOT"、 "オプション"、 "推奨"、 "SHOULD"、および "the" はならない、[5]に記載されているように解釈されるべきです。
Today, as described in [1], proxy chaining is widely deployed for the purposes of providing roaming services. In such systems, authentication/authorization and accounting packets are routed between a NAS device and a home server through a series of proxies. Consultation of the home server is required for password-based authentication, since the home server maintains the password database and thus it is necessary for the NAS to communicate with the home authentication server in order to verify the user's identity.
今日では、[1]、プロキシチェーンが広くローミングサービスを提供する目的のために配備されているに記載されているように。このようなシステムでは、認証/許可およびアカウンティングパケットがプロキシの一連のNASデバイスとホームサーバー間でルーティングされます。ホームサーバーの相談は、ホームサーバがパスワードデータベースを維持し、NASは、ユーザーの身元を確認するために、ホーム認証サーバと通信するためので、それは必要があるため、パスワードベースの認証に必要です。
Proxies serve a number of functions in roaming, including:
プロキシには、ローミング中に多くの機能を果たします。
Scalability improvement Authentication forwarding Capabilities adjustment Policy implementation Accounting reliability improvement Atomic operation
スケーラビリティの改善認証転送機能調整ポリシーの実装会計信頼性向上アトミック操作
Scalability improvement In large scale roaming systems, it is necessary to provide for scalable management of keys used for integrity protection and authentication.
大規模なローミングシステムではスケーラビリティの改善が、完全性保護と認証に使用されるキーのスケーラブルな管理を提供することが必要です。
Proxy chaining enables implementation of hierarchical forwarding within roaming systems, which improves scalability in roaming consortia based on authentication protocols without automated key management. Since RADIUS as described in [3] requires a shared secret for each client-server pair, a consortium of 100 roaming partners would require 4950 shared secrets if each partner were to contact each other directly, one for each partner pair. However, were the partners to route authentication requests through a central proxy, only 100 shared secrets would be needed, one for each partner. The reduction in the number of partner pairs also brings with it other benefits, such as a reduction in the number of bilateral agreements and accounting and auditing overhead. Thus, hierarchical routing might be desirable even if an authentiation protocol supporting automated key exchange were available.
プロキシの連鎖は、自動化された鍵管理なしの認証プロトコルに基づいてコンソーシアムをローミングでのスケーラビリティが向上し、ローミングシステム内の階層の転送の実装を可能にします。で説明したようにRADIUSので、各クライアントサーバペアの共有秘密を必要とする各パートナーは、直接、各パートナーのペアのための1つを互いに接触した場合、[3]、100人のローミングパートナーのコンソーシアムが4950の共有秘密を必要とします。しかし、中央プロキシ経由のルート認証要求へのパートナー、わずか100共有秘密は、各パートナーのための1を必要とされるであろうでした。パートナー対の数の減少はまた、それを、このような二国間協定と会計と監査のオーバーヘッドの数の減少などの他の利点をもたらします。このように、階層的なルーティングは、自動鍵交換をサポートauthentiationプロトコルが利用可能であったとしても望ましいかもしれません。
Capabilities adjustment As part of the authentication exchange with the home server, the NAS receives authorization parameters describing the service to be provided to the roaming user. Since RADIUS, described in [3], does not support capabilities negotiation, it is possible that the authorization parameters sent by the home server will not match those required by the NAS. For example, a static IP address could be specified that would not be routable by the NAS. As a result, capbilities adjustment is performed by proxies in order to enable communication between NASes and home servers with very different feature sets.
ホームサーバーとの認証交換の一部として機能調整は、NASは、ローミングユーザに提供するサービスを記述する許可パラメータを受け取ります。で説明RADIUSは、[3]、能力ネゴシエーションをサポートしていないので、ホームサーバから送信された認証パラメータは、NASで必要とされるものと一致しない可能性があります。たとえば、静的IPアドレスは、NASによってルーティング可能ではないことを指定することができました。その結果、capbilities調整が非常に異なる機能セットでのNASとホームサーバー間の通信を可能にするためにプロキシによって行われます。
As part of capabilities adjustment, proxies can edit attributes within the Access-Accept in order to ensure compatibility with the NAS. Such editing may include addition, deletion, or modification of attributes. In addition, in some cases it may be desirable for a proxy to edit attributes within an Access-Request in order to clean up or even hide information destined for the home server. Note that if the proxy edits attributes within the Access-Accept, then it is possible that the service provided to the user may not be the same as that requested by the home server. This creates the possibility of disputes arising from inappropriate capabilities adjustment.
能力調整の一環として、プロキシはNASとの互換性を確保するために、接続許可内の属性を編集することができます。このような編集は、属性の追加、削除、または修正を含むことができます。また、いくつかのケースでは、クリーンアップ、さらにはホームサーバ宛ての情報を隠すために、アクセス要求内の属性を編集するには、プロキシのが望ましいかもしれません。プロキシがアクセス - 受け入れ内の属性を編集した場合、ユーザーに提供されるサービスは、ホームサーバから要求されたものと同じではないかもしれない可能性があることに注意してください。これは、不適切な能力調整から生じる紛争の可能性を作成します。
Note that were roaming to be implemented based on an authentication/authorization protocol with built-in capability negotiation, proxy-based capabilities adjustment would probably not be necessary.
内蔵の能力交渉と認証/認証プロトコルに基づいて実施されるローミングたノートは、プロキシベースの機能の調整がおそらく必要ではないでしょう。
Authentication forwarding Since roaming associations frequently implement hierarchical forwarding in order to improve scalability, in order for a NAS and home server to communicate, authentication and accounting packets are forwarded by one or more proxies. The path travelled by these packets, known as the roaming relationship path, is determined from the Network Access Identifier (NAI), described in [6]. Since most NAS devices do not implement forwarding logic, a proxy is needed to enable forwarding of authentication and accounting packets. For reasons that are described in the security section, in proxy systems it is desirable for accounting and authentication packets to follow the same path.
団体が頻繁に通信するために、NASとホームサーバの順で、スケーラビリティを向上させるために、階層的な転送を実現するローミングので、認証転送は、認証およびアカウンティングパケットが一つ以上のプロキシによって転送されます。ローミング関係経路として知られるこれらのパケットが移動する経路は、[6]に記載のネットワークアクセス識別子（NAI）から決定されます。ほとんどのNASデバイスは転送ロジックを実装していないので、プロキシが認証およびアカウンティングパケットの転送を可能にするために必要とされています。アカウンティングおよび認証パケットが同じ経路に従うようにするためのプロキシ・システムでは、セキュリティセクションに記載されている理由であることが望ましいです。
Note: The way a proxy learns the mapping between NAI and the home server is beyond the scope of this document. This mapping can be accomplished by static configuration in the proxy, or by some currently undefined protocol that provides for dynamic mapping. For the purposes of this document, it is assumed that such a mapping capability exists in the proxy.
注意：プロキシがNAIとホームサーバとの間のマッピングを学習方法は、このドキュメントの範囲を超えています。このマッピングは、プロキシに、又は動的マッピングを提供するいくつかの現在未定義のプロトコルで静的な構成によって達成することができます。本文書の目的のために、このようなマッピング機能は、プロキシに存在することが想定されます。
Policy implementation In roaming systems it is often desirable to be able to implement policy. For example, a given partner may only be entitled to use of a given NAS during certain times of the day. In order to implement such policies, proxies may be implemented at the interface between administrative domains and programmed to modify authentication/authorization packets forwarded between the NAS and the home server. As a result, from a security point of view, a proxy implementing policy operates as a "man in the middle."
ローミングシステムでポリシーの実装では、ポリシーを実装することができることが望ましい場合が多いです。例えば、与えられたパートナーは、一日の特定の時間の間に与えられたNASの使用する権利を有することができます。そのような政策を実施するために、プロキシが管理ドメイン間の界面での実装およびNASとホームサーバー間で転送認証/認可パケットを修正するようにプログラムすることができます。その結果、セキュリティの観点から、ポリシーを実装するプロキシとして動作は「真ん中の男。」
Accounting reliability improvement In roaming systems based on proxy chaining, it is necessary for accounting information to be forwarded between the NAS and the home server. Thus roaming is inherently an interdomain application.
プロキシチェーンに基づいたシステムをローミングで会計の信頼性の向上、それはNASとホームサーバー間で転送される情報を占めるために必要です。したがって、ローミングは、本質的にドメイン間のアプリケーションです。
This represents a problem since the RADIUS accounting protocol, described in [4] is not designed for use on an Internet scale. Given that in roaming accounting packets travel between administrative domains, packets will often pass through network access points (NAPs) where packet loss may be substantial. This can result in unacceptable rates of accounting data loss.
これは、[4]、インターネット規模での使用のために設計されていないに記載のRADIUSアカウンティングプロトコルので問題です。アカウンティングパケットローミングに管理ドメイン間を移動することを考えると、パケットは、多くの場合、パケットロスがかなりのかもしれネットワークアクセスポイント（NAPの）を通過します。これは、会計データ損失の許容できない速度をもたらすことができます。
For example, in a proxy chaining system involving four systems, a one percent failure rate on each hop can result in loss of 3.9 percent of all accounting transactions. Placement of an accounting proxy near the NAS may improve reliability by enabling enabling persistent storage of accounting records and long duration retry.
例えば、4つのシステムを含むプロキシ・チェーンシステムにおいて、各ホップで1％の失敗率は、すべての会計取引の3.9％の損失をもたらすことができます。 NASの近くに会計プロキシの配置は、会計記録や長時間の再試行の永続ストレージを有効にする有効にすることで信頼性を改善することができます。
Atomic operation In order to ensure consistency among all parties required to process accounting data, it can be desirable to assure that transmission of accounting data is handled as an atomic operation. This implies that all parties on the roaming relationship path will receive and acknowledge the receipt of the accounting data for the operation to complete. Proxies can be used to ensure atomic delivery of accounting data by arranging for delivery of the accounting data in a serial fashion, as discussed in section 5.2.
会計データを処理するために必要なすべての当事者の間で一貫性を確保するためにアトミック動作は、会計データの送信は、アトミックオペレーションとして扱われる保証することが望ましいです。これは、ローミング関係のパス上のすべての関係者が受け取ると、操作が完了するまでの会計データの受信を確認することを意味します。プロキシは、セクション5.2で議論するように、シリアル方式で会計データの配信のために配置することにより、会計データの原子配送を保証するために使用することができます。
An example of a proxy chaining system is shown below.
プロキシチェーンシステムの一例を以下に示します。
(request) (request) (request)
NAS ----------> Proxy1 ----------> Proxy2 ----------> Home
(reply) (reply) (reply) Server
<--------- <--------- <---------
In the above diagram, the NAS generates a request and sends it to Proxy1. Proxy1 forwards the request to Proxy2 and Proxy2 forwards the request to the Home Server. The Home Server generates a reply and sends it to Proxy2. Proxy2 receives the reply, matches it with the request it had sent, and forwards a reply to Proxy1. Proxy1 matches the reply with the request it sent earlier and forwards a reply to the NAS. This model applies to all requests, including Access Requests and Accounting Requests.
上記の図では、NASはリクエストを生成し、PROXY1に送信します。 PROXY1はPROXY2に要求を転送し、PROXY2は、ホームサーバーに要求を転送します。ホームサーバーは応答を生成し、PROXY2に送信します。 PROXY2は、それが送信された要求とそれにマッチし、応答を受信し、PROXY1への応答を転送します。 PROXY1は、それが以前に送信した要求と応答に一致し、NASへの応答を転送します。このモデルは、アクセス要求およびアカウンティング要求を含むすべての要求に適用されます。
Except for the two cases described below, a proxy server such as Proxy2 in the diagram above SHOULD NOT send a Reply packet to Proxy1 without first having received a Reply packet initiated by the Home Server. The two exceptions are when the proxy is enforcing policy as described in section 5.1 and when the proxy is acting as an accounting store (as in store and forward), as described in section 5.2.
下記の2例を除いて、上図のようにPROXY2などのプロキシサーバーは、最初のホームサーバーによって開始さReplyパケットを受信せずにPROXY1に返信パケットを送信することはできません。セクション5.1で説明したように、プロキシは、ポリシーを実施したとき、セクション5.2で説明したようにプロキシが、（ストアアンドフォワードのように）アカウンティング・ストアとして動作しているときに、2つの例外があります。
The RADIUS protocol described in [3] does not provide for end-to-end security services, including integrity or replay protection, authentication or confidentiality. As noted in the security considerations section, this omission results in several security problems within proxy chaining systems.
で説明したRADIUSプロトコルは、[3]整合性や再生保護、認証や機密性など、エンドツーエンドのセキュリティサービスのために提供されていません。プロキシチェーンシステム内のいくつかのセキュリティ上の問題におけるセキュリティの考慮事項の項で述べたように、この省略は結果。
Proxies are frequently used to implement policy in roaming situations. Proxies implementing policy MAY reply directly to Access-Requests without forwarding the request. When replying directly to an Access-Request, the proxy MUST reply either with an Access-Reject or an Access-Challenge packet. A proxy MUST NOT reply directly with an Access-Accept. An example of this would be when the proxy refuses all connections from a particular realm during prime time. In this case the home server will never receive th Access-Request. This situation is shown below:
プロキシは、頻繁に状況をローミングでポリシーを実装するために使用されています。ポリシーを実装するプロキシは、要求を転送することなく、アクセス・リクエストに直接応答することができます。アクセス要求に直接返信すると、プロキシは、いずれかのアクセス拒否またはアクセスチャレンジパケットで返答しなければなりません。プロキシは、受け入れAccessで直接返信してはなりません。プロキシがプライムタイムの間、特定のレルムからのすべての接続を拒否したときに、この例のようになります。この場合、ホームサーバーは、番目のアクセス要求を受信することはありません。このような状況を以下に示します。
(request) (request)
NAS ----------> Proxy1 ----------> Proxy2 Home
(reply) (reply) Server
<--------- <---------
A proxy MAY also decide to Reject a Request that has been accepted by the home server. This could be based on the set of attributes returned by the home server. In this case the Proxy SHOULD send an Access-Reject to the NAS and an Accounting-Request with Acct-Status-Type=Proxy-Stop (6) to the home server. This lets the home server know that the session it approved has been denied downstream by the proxy. However, a proxy MUST NOT send an Access-Accept after receiving an Access-Reject from a proxy or from the home server.
プロキシは、ホームサーバーによって承認されたリクエストを拒否することもできます。これは、ホームサーバーによって返された属性のセットに基づくことができます。この場合、プロキシは、NASとホームサーバにアカウンティング・ステータス・タイプ=プロキシ・ストップ（6）とアカウンティング要求に拒否アクセスを送るべきです。これは、ホームサーバーは、それが承認されたセッションがプロキシによって下流拒否されたことを知ることができます。しかし、プロキシはプロキシからまたはホームサーバーから拒否アクセスを受けた後、受け入れのアクセスを送ってはいけません。
(Access-Req) (Access-Req) (Access-Req)
NAS ----------> Proxy1 ----------> Proxy2 ----------> Home
(Access-Reject) (Access-Accept) (Access-Accept) Server
<--------- <--------- <---------
(AcctPxStop) (AcctPxStop)
----------> ---------->
As described above, a proxy MUST NOT reply directly with an Access-Accept, and MUST NOT reply with an Access-Accept when it has received an Access-Reject from another proxy or Home Server. As a result, in all cases where an accounting record is to be generated (accepted sessions), no direct replies have occurred, and the Access-Request and Access-Accept have passed through the same set of systems.
前述したように、プロキシは、アクセス・受け入れで直接返信てはならない、とのAccess-受け入れ、それが別のプロキシまたはホームサーバーから拒否アクセスを受けたときで返答してはなりません。その結果、アカウンティングレコードが生成されるすべてのケース（受け入れセッション）で、何ら直接的な回答は発生していない、とアクセス要求とアクセス - 受け入れシステムの同じセットを通過しました。
In order to allow proxies to match incoming Accounting-Requests with previously handled Access-Requests and Access-Accepts, a proxy SHOULD route the Accounting-Request along the same realm path travelled in authentication/authorization. Note that this does not imply that accounting packets will necessarily travel the identical path, machine by machine, as did authentication/authorization packets. This is because it is conceivable that a proxy may have gone down, and as a result the Accounting-request may need to be forwarded to an alternate server. It is also conceivable that authentication/authorization and accounting may be handled by different servers within a realm.
プロキシが以前にアクセス - 要求を取り扱い、アクセス・受け入れ、同じレルム経路に沿っアカウンティング - 要求が認証/認可に移動プロキシSHOULD経路と着信アカウンティング - 要求と一致することを可能にするために。認証/認可パケットをしたとして、これは、必ずしも機械で同じパス、マシンを移動することアカウンティングパケットを意味するものではないことに注意してください。プロキシがダウンしたことが考えられるので、これは、結果として、会計要求は、代替サーバに転送する必要があるかもしれません。認証/許可およびアカウンティング、レルム内の別のサーバーによって処理されることも考えられます。
The Class attribute can be used to match Accounting Requests with prior Access Requests. It can also be used to match session log records between the home Server, proxies, and NAS. This matching can be accomplished either in real-time (in the case that authentication and accounting packets follow the same path, machine by machine), or after the fact.
クラス属性は、以前のアクセス要求とアカウンティング要求を一致させるために使用することができます。また、ホームサーバ、プロキシ、およびNASの間のセッションのログレコードを一致させるために使用することができます。この照合はリアルタイムで（認証およびアカウンティングパケットがマシンによって、同じパス、マシンに従った場合に）、または事実の後のいずれかで達成することができます。
Home servers SHOULD insert a unique session identifier in the Class attribute in an Access-Accept and Access-Challenge. Proxies and NASes MUST forward the unmodified Class attribute. The NAS MUST include the Class attribute in subsequent requests, in particular for Accounting-Requests. The sequence of events is shown below:
ホームサーバは、接続許可とアクセスチャレンジのクラス属性に固有のセッション識別子を挿入する必要があります。プロキシとのNASは、修飾されていないクラス属性を転送する必要があります。 NASは、アカウンティング要求の特に、後続の要求のクラス属性を含まなければなりません。イベントのシーケンスを以下に示します。
Authentication/Authorization
認証/承認
--------> --------> --------->
NAS Proxy1 Proxy2 Home (add class)
<-class-- <-class- <-class--
Accounting
経理
(Accounting-req) (Accounting-req) (Accounting-req)
w/class w/class w/class
NAS ----------> Proxy1 ----------> Proxy2 ----------> Home
(Accounting-reply) (Accounting-reply)(Accounting-reply) Server
<--------- <--------- <---------
Since there is no need to implement policy in accounting, a proxy MUST forward all Accounting Requests to the next server on the path. The proxy MUST guarantee that the Accounting Request is received by the End Server and all intermediate servers. The proxy may do this either by: 1) forwarding the Accounting Request and not sending a Reply until it receives the matching Reply from the upstream server, or 2) acting as a store point which takes responsibility for reforwarding the Accounting Request until it receives a Reply.
会計でポリシーを実装する必要がないので、プロキシは、パス上の次のサーバにすべてのアカウンティング要求を転送する必要があります。プロキシはアカウンティング要求をエンドサーバーおよびすべての中間サーバで受信されることを保証しなければなりません。 1）課金要求を転送し、それが上流のサーバから一致する応答を受信するまで、応答を送信しない、または2）それが受信するまでアカウンティング要求を再転送するための責任を負うストア点として作用する：プロキシはいずれかによってこれを行うことができます応答。
Note that when the proxy does not send a reply until it receives a matching reply, this ensures that Accounting Start and Stop messages are received and can be logged by all servers along the roaming relationship path. If one of the servers is not available, then the operation will fail. As a result the entire accounting transaction will either succeed or fail as a unit, and thus can be said to be atomic.
それが一致する応答を受信するまで、プロキシは応答を送信しないとき、これは会計開始と停止メッセージが受信され、ローミング関係経路に沿って、すべてのサーバによってログに記録されることを保証することに注意してください。いずれかのサーバーが使用できない場合、操作は失敗します。その結果、全体の会計トランザクションは成功するか失敗するユニットとして、したがって、アトミックであると言うことができますどちらか。
Where store and forward is implemented, it is possible that one or more servers along the roaming relationship path will not receive the accounting data while others will. The accounting operation will not succeed or fail as a unit, and is therefore not atomic. As a result, it may not be possible for the roaming partners to reconcile their audit logs, opening new opportunities for fraud. Where store and forward is implemented, forwarding of Accounting Requests SHOULD be done as they are received so the downstream servers will receive them in a timely way.
ストアアンドフォワードが実装されている場合、他の人がしますが、ローミング関係経路に沿って、1つ以上のサーバーが、会計データを受信しない可能性があります。会計操作が成功するか失敗するユニットとして、したがって、アトミックではありませんではないでしょう。ローミングパートナーが監査ログを調整するため、結果として、それは詐欺のための新たな機会を開くこと、できないことがあります。ストアアンドフォワードが実装されている場合、下流のサーバーがタイムリーな方法でそれらを受け取ることになりますので、それらが受信されると、アカウンティング要求の転送が行われるべきです。
Note that there are cases where a proxy will need to forward an Accounting packet to more than one system. For example, in order to allow for proper accounting in the case of a NAS that is shutting down, the proxy can send an Accounting-Request with Acct-Status-Type=Accounting-Off (8) to all realms that it forwards to. In turn, these proxies will also flood the packet to their connected realms.
プロキシが複数のシステムに会計パケットを転送する必要があります場合があることに注意してください。たとえば、シャットダウンされたNASの場合は適切な会計処理を可能にするために、プロキシは、（8）、それは転送するすべてのレルムにアカウンティング・ステータス・タイプ=会計オフとアカウンティング要求を送信することができます。ターンでは、これらのプロキシはまた、彼らの接続のレルムにパケットをフラッディングします。
[1] Aboba, B., Lu J., Alsop J., Ding J. and W. Wang, "Review of Roaming Implementations", RFC 2194, September 1997.
[1] Aboba、B.、陸J.、オールソップJ.、丁J.およびW.ワング、 "ローミング実装のレビュー"、RFC 2194、1997年9月。
[2] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999.
[2] Aboba、B.およびG.ゾルン、 "ローミングプロトコルを評価するための基準"、RFC 2477、1999年1月を。
[3] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[3] Rigney、C.、ルーベンス、A.、シンプソン、W.及びS. Willensを、 "リモート認証ダイヤルインユーザーサービス（RADIUS）で"、RFC 2138、1997年4月。
[4] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
[4] Rigney、C.、 "RADIUSアカウンティング"、RFC 2139、1997年4月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[6] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[6] Aboba、B.及びM. Beadles、 "ネットワークアクセス識別子"、RFC 2486、1999年1月。
The RADIUS protocol described in [3] was designed for intra-domain use, where the NAS, proxy, and home server exist within a single administrative domain, and proxies may be considered a trusted component. However, in roaming the NAS, proxies, and home server will typically be managed by different administrative entities. As a result, roaming is inherently an inter-domain application, and proxies cannot necessarily be trusted. This results in a number of security threats, including:
[3]に記載のRADIUSプロトコルはNAS、プロキシ、及びホームサーバは、単一の管理ドメイン内に存在する場合、ドメイン内の使用のために設計された、及びプロキシは、信頼できるコンポーネントと考えることができます。しかし、NASをローミングで、プロキシ、およびホームサーバーは、通常、異なる管理エンティティによって管理されます。その結果、ローミングは本質的に、ドメイン間のアプリケーションであり、プロキシは必ずしも信頼することはできません。これは、セキュリティ上の脅威を含め、多数の結果：
Message editing Attribute editing Theft of passwords Theft and modification of accounting data Replay attacks Connection hijacking Fraudulent accounting
会計データのリプレイのパスワードの盗難や変更の盗難を編集するメッセージ編集属性は、接続の乗っ取り詐欺会計を攻撃します
Through the use of shared secrets it is possible for proxies operating in different domains to establish a trust relationship. However, if only hop-by-hop security is available then untrusted proxies are capable of perpetrating a number of man-in-the-middle attacks. These include modification of messages.
異なるドメインで動作しているプロキシが信頼関係を確立するための共有秘密を使用することによりそれが可能です。しかし、唯一のホップバイホップのセキュリティが利用可能であるならば、信頼できないプロキシは、man-in-the-middle攻撃の数を犯すことができます。これらは、メッセージの変更が含まれます。
For example, an Access-Accept could be substituted for an Access-Reject, and without end-to-end integrity protection, there is no way for the NAS to detect this. On the home server, this will result in an accounting log entry for a session that was not authorized. However, if the proxy does not forward accounting packets or session records to the home server, then the home server will not be able to detect the discrepancy until a bill is received and audited.
たとえば、Access-受け入れは、アクセス拒否の代わりに用いることができる、およびエンドツーエンドの完全性保護なしで、NASは、これを検出するための方法はありません。ホームサーバーでは、これは、許可されなかったセッションのアカウンティングログのエントリになります。プロキシが前方アカウンティングパケットまたはセッション記録ホームサーバーにない場合は、その後、ホームサーバーは、法案を受信し、監査されるまで、不一致を検出することができません。
Note that a proxy can also send an Access-Reject to the NAS after receiving an Access-Accept from the home server. This will result in an authentication log entry without a corresponding accounting log entry. Without the proxy sending an Accounting-Request with Acct-Status-Type=Proxy-Stop (6) to the home server, then there will be no way for the home server to determine whether the discrepancy is due to policy implementation or loss of accounting packets. Thus the use of Acct-Status-Type=Proxy-Stop can be of value in debugging roaming systems.
プロキシは、ホームサーバから-受け入れアクセスを受けた後、NASへの拒否アクセスを送ることができることに注意してください。これは、対応するアカウンティングログエントリなしで認証ログエントリになります。プロキシはアカウンティング・ステータス・タイプ=プロキシストップとアカウンティング要求を送信せずに（6）ホームサーバーに、その後、矛盾が政策の実施や会計の損失によるものであるかどうかを判断するホームサーバーの方法がないだろうパケット。したがって、アカウンティング・ステータス・タイプ=プロキシ・ストップの使用はローミングシステムのデバッグに価値があることができます。
It should be noted that even if end-to-end security were to be available, a number of sticky questions would remain. While the end-points would be able to detect that the message from the home server had been modified by an intermediary, the question arises as to what action should be taken. While the modified packet could be silently discarded, this could affect the ability of the home server to . accept an Acct-Status-Type=Proxy-Stop message from an intermediate proxy. Since this message would not be signed by the NAS, it may need to be dropped by the home server.
エンドツーエンドのセキュリティを利用できるようにしたとしても、粘着性の質問の数が残ることに留意すべきです。エンドポイントは、ホームサーバーからのメッセージが仲介によって変更されたことを検出することができるだろうが、問題は、どのような行動には注意する必要があるとして生じます。変更されたパケットは静かに捨てられる可能性がありますが、これはにホームサーバーの能力に影響を与える可能性があります。中間プロキシからのAcct-STATUS-タイプ=プロキシ停止メッセージを受け入れます。このメッセージは、NASによって署名されないので、それがホームサーバーでドロップする必要があるかもしれません。
This is similar to the problem that IPSEC-capable systems face in making use of ICMP messages from systems with whom they do not have a security association. The problem is more difficult here, since in RADIUS retransmission is driven by the NAS. Therefore the home server does not receive acknowledgement for Access-Accepts and thus would have no way of knowing that its response has not been honored.
これは、IPSEC対応システムは、彼らがセキュリティアソシエーションを持っていない人とシステムからのICMPメッセージを利用することで直面する問題に似ています。 RADIUSの再送信にNASによって駆動されるため問題は、ここではより困難です。アクセス - 受け入れ、したがって、その応答が表彰されていないことを知る方法はありませんのためにそのためのホームサーバーは、確認応答を受信しません。
RADIUS as defined in [3] does not provide for end-to-end security or capabilities negotiation. As a result there is no way for a home server to securely negotiate a mutually acceptable configuration with the NAS or proxies. As a result, a number of attribute editing attacks are possible.
で定義されているRADIUS [3]は、エンドツーエンドのセキュリティや機能の交渉のために提供されていません。その結果、安全にNASやプロキシを相互に受け入れ可能な設定を交渉するホームサーバのための方法はありません。その結果、攻撃を編集する属性の数が可能です。
For example, EAP attributes might be removed or modified so as to cause a client to authenticate with EAP MD5 or PAP, instead of a stronger authentication method. Alternatively, tunnel attributes might be removed or modified so as to remove encryption, redirect the tunnel to a rogue tunnel server, or otherwise lessen the security provided to the client. The mismatch between requested and received services may only be detectable after the fact by comparing the Access-Accept attributes against the attributes included in the Accounting-Request. However, without end-to-end security services, it is possible for a rogue proxy to cover its tracks.
代わりに、より強力な認証方法のEAP MD5またはPAP、で認証するためにクライアントを引き起こすように例えば、EAP属性は削除または変更される可能性があります。代替的に、トンネル属性が削除または、暗号化を削除する不正トンネルサーバにトンネルをリダイレクトする、またはそうでなければ、クライアントに提供されるセキュリティを軽減するように修正されるかもしれません。要求されたと受け取ったサービスの間のミスマッチはアカウンティング要求に含まれた属性に対して、接続許可の属性を比較することによって、事実の後に検出可能であってもよいです。しかし、エンドツーエンドのセキュリティサービスなしで、それはその曲をカバーするために、不正なプロキシのために可能です。
Due to the complexity of proxy configuration, such attacks need not involve malice, but can occur due to mis-configuration or implementation deficiencies. Today several proxy implementations remove attributes that they do not understand, or can be set up to replace attribute sets sent in the Access-Accept with sets of attributes appropriate for a particular NAS.
プロキシ設定の複雑さのため、このような攻撃は、悪意を伴う必要はないが、設定ミスや実装の不備が原因で発生する可能性があります。今日、いくつかのプロキシの実装は、彼らが理解していない属性を削除、または特定のNASのための適切な属性のセットを、受け入れAccessで送られた属性セットを交換するように設定することができます。
In practice, it is not possible to define a set of guidelines for attribute editing, since the requirements are very often implementation-specific. At the same time, protection against inappropriate attribute editing is necessary to guard against attacks and provide assurance that users are provisioned as directed by the home server.
要件が非常に頻繁に実装固有であるため、実際には、属性を編集するためのガイドラインのセットを定義することはできません。同時に、不適切な属性の編集に対する保護は、攻撃から保護し、ホームサーバーの指示に従って、ユーザーがプロビジョニングされていることを保証を提供することが必要です。
Since it is not possible to determine beforehand whether a given attribute is editable or not, a mechanism needs to be provided to allow senders to indicate which attributes are editable and which are not, and for the receivers to detect modifications of "non-editable" attributes. Through implementation of end-to-end security it may be possible to detect unauthorized addition, deletion, or modification of integrity-protected attributes. However, it would still possible for a rogue proxy to add, delete or modify attributes that are not integrity-protected. If such attributes influence subsequent charges, then the possibility of fraud would remain.
それが予め指定された属性が編集可能であるか否かを決定することは不可能であるので、メカニズムは送信者が編集可能な属性を示すことを可能にするために提供する必要があり、これではなく、受信機は、「編集不可」の改変を検出します属性。エンドツーエンドのセキュリティの実装を通じて、不正な追加、削除、または完全性保護された属性の変更を検出することが可能です。しかし、それはまだ可能性、完全性保護されていない属性を追加、削除または変更する不正なプロキシのだろう。このような属性は、その後の料金に影響を与える場合は、詐欺の可能性が残ります。
RADIUS as defined in [3] does not provide for end-to-end confidentiality. As a result, where clients authenticate using PAP, each proxy along the path between the local NAS and the home server will have access to the cleartext password. In many circumstances, this represents an unacceptable security risk.
[3]、エンドツーエンドの機密性を提供しないで定義されているRADIUS。クライアントがPAPを使用して認証結果として、ローカルNASとホームサーバとの間の経路に沿った各プロキシは、クリアテキストパスワードにアクセスする必要があります。多くの状況では、これは容認できないセキュリティリスクを表します。
Typically in roaming systems, accounting packets are provided to all the participants along the roaming relationship path, in order to allow them to audit subsequent invoices. RADIUS as described in [3] does not provide for end-to-end security services, including integrity protection or confidentiality. Without end-to-end integrity protection, it is possible for proxies to modify accounting packets or session records. Without end-to-end confidentiality, accounting data will be accessible to proxies. However, if the objective is merely to prevent snooping of accounting data on the wire, then IPSEC ESP can be used.
典型的にはローミングシステムでは、アカウンティング・パケットは、それらがその後の請求書を監査することを可能にするために、ローミング関係経路に沿ってすべての参加者に提供されます。で説明したようにRADIUSは、[3]完全性保護や機密性など、エンドツーエンドのセキュリティサービスのために提供されていません。プロキシはアカウンティングパケットまたはセッションレコードを変更するためのエンドツーエンドの完全性保護がなければ、それが可能です。エンドツーエンドの機密性がなければ、会計データは、プロキシにアクセスできるようになります。目的は単にワイヤ上の会計データのスヌーピングを防ぐことにある場合は、その後、IPSEC ESPを使用することができます。
In this attack, a man in the middle or rogue proxy collects CHAP-Challenge and CHAP-Response attributes, and later replays them. If this attack is performed in collaboration with an unscrupulous ISP, it can be used to subsequently submit fraudulent accounting records for payment. The system performing the replay need not necessarily be the one that initially captured the CHAP Challenge/Response pair.
この攻撃では、ミドルまたは不正なプロキシの男は、CHAPチャレンジとCHAPレスポンスの属性を収集し、それらを後で再生します。この攻撃は、不謹慎なISPと協力して行われた場合、その後、支払いのために不正会計記録を提出するために使用することができます。リプレイを実行するシステムは、必ずしも最初にCHAPチャレンジ/レスポンス対を捕獲一つである必要はありません。
While RADIUS as described in [3] is vulnerable to replay attacks, without roaming the threat is restricted to proxies operating in the home server's domain. With roaming, such an attack can be mounted by any proxy capable of reaching the home server.
で説明したようにRADIUSながら[3]の脅威は、ホームサーバーのドメインで動作しているプロキシに制限されているローミングせずに、リプレイ攻撃に対して脆弱です。ローミングでは、このような攻撃は、ホームサーバーに到達することができる任意のプロキシでマウントすることができます。
In this form of attack, the attacker attempts to inject packets into the conversation between the NAS and the home server. RADIUS as described in [3] is vulnerable to such attacks since only Access-Reply and Access-Challenge packets are authenticated.
この形式の攻撃では、攻撃者がNASとホームサーバとの間の会話にパケットを注入しようとします。のみアクセス-返信アクセスチャレンジパケットが認証されているために記載されているようにRADIUS [3]はそのような攻撃に対して脆弱です。
In this form of attack, a local proxy transmits fraudulent accounting packets or session records in an effort to collect fees to which they are not entitled. This includes submission of packets or session records for non-existent sessions. Since in RADIUS as described in [3], there is no end-to-end security, a rogue proxy may insert or edit packets without fear of detection.
この形式の攻撃では、ローカルプロキシは、彼らが権利を有するされていないに料金を徴収するための努力で不正会計パケットかセッション記録を送信します。これは、存在しないセッションのためのパケットまたはセッション記録の提出を含んでいます。 [3]、何エンドツーエンドのセキュリティが存在しないで説明したようにRADIUSであるので、不正なプロキシが検出の恐れなしにパケットを挿入したり、編集することができます。
In order to detect submissions of accounting packets or session records for non-existent sessions, parties receiving accounting packets or session records would be prudent to reconcile them with the authentication logs. Such reconciliation is only typically possible when the party acts as an authentication proxy for all sessions for which an accounting record will subsequently be submitted.
存在しないセッションのアカウンティングパケットまたはセッション記録の提出を検出するために、会計パケットかセッション記録を受ける当事者は、認証ログでそれらを調整するのが賢明だろう。このような和解は、当事者がアカウンティングレコードはその後に提出されるため、すべてのセッションのための認証プロキシとして動作する場合にのみ、通常可能です。
In order to make reconciliation easier, home servers involved in roaming include a Class attribute in the Access-Accept. The Class attribute uniquely identifies a session, so as to allow an authentication log entry to be matched with a corresponding accounting packet or session record.
簡単に和解を作るためには、ローミングに関与ホームサーバーは、接続許可のクラス属性が含まれます。対応する会計パケットかセッション記録と照合する認証ログのエントリを可能にするように、クラス属性は一意に、セッションを識別します。
If reconciliation is put in place and all accounting log entries without a corresponding authentication are rejected, then the attacker will need to have obtained a valid user password prior to submitting accounting packets or session records on non-existent sessions. While use of end-to-end security can defeat unauthorized injection or editing of accounting or authentication packets by intermediate proxies, other attacks remain feasible. For example, unless replay protection is put in place, it is still feasible for an intermediate proxy to resubmit authentication or accounting packets or session records. In addition, end-to-end security does not provide protection against attacks by the local proxy, since this is typically where end-to-end security will be initiated. To detect such attacks, other measures need to be put in place, such as systems for detecting unusual activity of ISP or user accounts, or for determining whether a user or ISP account is within their credit limit.
和解が所定の位置に置かれ、対応する認証なしですべてのアカウンティングログエントリが拒否された場合、攻撃者が実在しないセッションでアカウンティングパケットまたはセッション記録を提出する前に、有効なユーザー・パスワードを取得している必要があります。エンドツーエンドのセキュリティの使用は、中間プロキシが会計または認証パケットの不正注入や編集を倒すことができますが、他の攻撃が可能なまま。リプレイ保護が所定の位置に置かれていない限り、中間プロキシが認証またはアカウンティングパケットまたはセッションレコードを再送信するために例えば、それはまだ実現可能です。エンドツーエンドのセキュリティが開始される場所これは、一般的であるため、また、エンドツーエンドのセキュリティは、ローカルプロキシによる攻撃に対する保護を提供していません。このような攻撃を検出するために、他の措置には、ISPやユーザーアカウントの異常な活性を検出するための、またはユーザやISPのアカウントは自分のクレジット限度内であるか否かを判断するためのシステムとして、場所においておく必要があります。
Note that implementation of the store and forward approach to proxy accounting makes it possible for some systems in the roaming relationship path to receive accounting records that other systems do not get. This can result in audit discrepancies. About the best that is achievable in such cases is to verify that the accounting data is missing by checking against the authentication logs.
ローミング関係のパスにおけるいくつかのシステムは、他のシステムは取得しない会計記録を受信するための店や代理会計に転送アプローチの実装に注意することが可能となります。これは、監査の不一致をもたらす可能性があります。このような場合に達成可能であること最もよいについて会計データは、認証ログに対してチェックすることにより、欠落していることを確認することです。
Thanks to Pat Calhoun of Sun Microsystems, Mark Beadles of CompuServe, Aydin Edguer of Morningstar, Bill Bulley of Merit, and Steven P. Crain of Shore.Net for useful discussions of this problem space.
この問題空間の有益な議論のためのサン・マイクロシステムズのパットカルフーン、コンピュサーブのマークBeadles、モーニングスターのアイディンEdguer、メリットのビルBulley、およびShore.NetのスティーブンP.クレインに感謝します。
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052
Phone: 425-936-6605 EMail: bernarda@microsoft.com
電話：425-936-6605 Eメール：bernarda@microsoft.com
John R. Vollbrecht Merit Network, Inc. 4251 Plymouth Rd. Ann Arbor, MI 48105-2785
ジョンR. Vollbrechtネットワーク株式会社4251プリマスRdのがメリット。アナーバー、MI 48105-2785
Phone: 313-763-1206 EMail: jrv@merit.edu
電話：313-763-1206 Eメール：jrv@merit.edu
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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機能のための基金は現在、インターネット協会によって提供されます。