RFC2607 日本語訳
2607 Proxy Chaining and Policy Implementation in Roaming. B. Aboba, J.Vollbrecht. June 1999. (Format: TXT=33271 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Aboba
Request for Comments: 2607 Microsoft Corporation
Category: Informational J. Vollbrecht
Merit Networks, Inc.
June 1999
Abobaがコメントのために要求するワーキンググループB.をネットワークでつないでください: 2607年のマイクロソフト社カテゴリ: 情報のJ.VollbrechtはInc.1999年6月にネットワークに値します。
Proxy Chaining and Policy Implementation in Roaming
ローミングにおけるプロキシ推論と政策の実施
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
1. Abstract
1. 要約
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.
しかしながら、セキュリティ問題部で注意されるように、本書では概説されたテクニックはまた、影響されやすいとしての外部関係者からローミングパートナーによって自分たちで犯された詐欺まで攻撃するために被害を受け易いです。 その結果、そのようなメソッドはインターネットで広いスケール展開に適していません。
2. Terminology
2. 用語
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.
ネットワークAccess Server Network Access Server(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サーバThisは[3]、および[4]で説明される会計で説明されたプロトコルで認証/承認に備えるサーバです。
Aboba & Vollbrecht Informational [Page 1] RFC 2607 Proxy Chaining and Policy in Roaming June 1999
1999年6月に移動することにおけるAboba&Vollbrechtの情報[1ページ]のRFC2607プロキシ推論と方針
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プロキシIn注文、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認証と会計要求のルーティングに備えるネットワークAccess Identifier In命令(PPP(Network Access IdentifierかNAIとして、知られている)とその後のRADIUS認証と会計要求で使用されるuserID分野)は構造を含むことができます。 この構造は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.
関係Roamingに移動して、関係は会社とISPとの関係を含んでいます、aの中の同輩ISPの中の関係が協会、およびISPとaローミングコンソーシアムとの関係に移動して。 地方のISPの認証プロキシとホーム認証サーバの間の経路を形成する関係のセットはローミング関係経路として一緒に、知られています。
3. Requirements language
3. 要件言語
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [5].
そして、このドキュメント、「5月」というキーワードで「必須、「必須NOT」、「任意」の、そして、「お勧め」の“SHOULD"、「」、[5]で説明されるように解釈されることになっていてください、」であるべきです
4. Introduction
4. 序論
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がホーム認証サーバとコミュニケートするのが、ユーザのアイデンティティについて確かめるのに必要です。
Aboba & Vollbrecht Informational [Page 2] RFC 2607 Proxy Chaining and Policy in Roaming June 1999
1999年6月に移動することにおけるAboba&Vollbrechtの情報[2ページ]のRFC2607プロキシ推論と方針
4.1. Advantages of proxy chaining
4.1. プロキシ推論の利点
Proxies serve a number of functions in roaming, including:
プロキシはローミング、包含における多くの機能を果たします:
Scalability improvement Authentication forwarding Capabilities adjustment Policy implementation Accounting reliability improvement Atomic operation
スケーラビリティ改良Authentication推進Capabilities調整Policy実装Accounting信頼性の改良Atomic操作
Scalability improvement
In large scale roaming systems, it is necessary to provide for
scalable management of keys used for integrity protection and
authentication.
スケーラビリティ改良In大規模ローミングシステム、保全保護と認証に使用されるキーのスケーラブルな管理に備えるのが必要です。
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.
プロキシ推論はローミングシステムの中の階層的な推進の実装を可能にします。(推進は自動化されたかぎ管理なしで認証プロトコルに基づくコンソーシアムに移動する際にスケーラビリティを改良します)。 [3]で説明されるRADIUSがそれぞれのクライアント/サーバ組のために共有秘密キーを必要とするので、各パートナーが直接互いに連絡するなら、100人のローミングパートナーの共同体は4950の共有秘密キーを必要とするでしょうに、それぞれのパートナー組単位の1つ。 しかしながら、パートナーが主要なプロキシを通して認証要求を発送するなら、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.
ホームサーバがある認証交換の能力調整As部分、NASはローミングユーザに提供するためにサービスについて説明する承認パラメタを受け取ります。 [3]で説明されたRADIUSが、能力が交渉であるとサポートしないので、ホームサーバによって送られた承認パラメタがNASによって必要とされたものに合っていないのは、可能です。 例えば、NASで発送可能でない静的IPアドレスは指定できました。 その結果、capbilities調整は、非常に異なった特徴セットでNASesとホームサーバとのコミュニケーションを可能にするためにプロキシによって実行されます。
Aboba & Vollbrecht Informational [Page 3] RFC 2607 Proxy Chaining and Policy in Roaming June 1999
1999年6月に移動することにおけるAboba&Vollbrechtの情報[3ページ]のRFC2607プロキシ推論と方針
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との互換性を確実にするために中でAccess受け入れるのを結果と考えます。 そのような編集は属性の追加、削除、または変更を含むかもしれません。 いくつかの場合、さらに、プロキシが掃除するためにAccess-要求の中で属性を編集するか、またはホームサーバのために運命づけられた情報を隠すのさえ、望ましいかもしれません。これが論争が不適当な能力調整から起こる可能性を作成することに注意してください。プロキシが属性を編集するなら、中では、Access受け入れて、次に、それがホームサーバから要求したようにユーザに提供されたサービスが同じでないことが、可能です。
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.
認証推進Sinceローミング協会はスケーラビリティを改良するために頻繁に階層的な推進を実装します、NASにおいて整然として、伝えるホームサーバ、認証、および会計パケットは1つ以上のプロキシによって進められます。 ローミング関係経路として知られているこれらのパケットによって旅行された経路は[6]で説明されたNetwork Access Identifier(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
政策を実施できるのがしばしば望ましい政策の実施Inローミングシステム。 例えば、与えられたパートナーは1日のある回の間、与えられたNASの使用の権利を与えられるだけであるかもしれません。 そのような政策を実施するために、プロキシは、管理ドメインの間のインタフェースで実装されて、パケットが. NASとホームサーバAsの間で結果を送った認証/承認を変更するようにプログラムされるかもしれません、セキュリティ観点から、プロキシ実装する方針
Aboba & Vollbrecht Informational [Page 4] RFC 2607 Proxy Chaining and Policy in Roaming June 1999
1999年6月に移動することにおけるAboba&Vollbrechtの情報[4ページ]のRFC2607プロキシ推論と方針
operates as a "man in the middle."
「中央の男性」として、作動します。
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.
プロキシ推論に基づく会計信頼性の改良Inローミングシステム、NASとホームサーバの間に課金情報を転送するのが必要です。その結果、本来ローミングはinterdomainアプリケーションです。
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会計がインターネットスケールにおける使用のために設計されていないので、これは問題を表します。 ローミング会計では、パケットが管理ドメインの間を移動すると、パケットはしばしばネットワークアクセスポイント(NAPs)をパケット損失が実質的であるかもしれないところに通り抜けるでしょう。 これは会計データの損失の容認できない速度をもたらすことができます。
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.
会計データを処理するのに必要であるすべてのパーティーで一貫性があることを保証する原子操作In命令、会計データの伝達が原子操作として扱われることを保証するのは望ましい場合があります。 これは、ローミング関係経路のすべてのパーティーが操作が完成する会計データの領収書を受け取って、受け取ったことを知らせるのを含意します。 連続のファッションにおける、会計データの配送を準備することによって会計データの原子配送を確実にするのにプロキシを使用できます、セクション5.2で議論するように。
5. Proxy chaining
5. プロキシ推論
An example of a proxy chaining system is shown below.
プロキシ推論システムに関する例は以下に示されます。
(request) (request) (request)
NAS ----------> Proxy1 ----------> Proxy2 ----------> Home
(reply) (reply) (reply) Server
<--------- <--------- <---------
(要求します) (要求)(要求する)NAS---------->Proxy1---------->Proxy2---------->ホーム(回答)(回答)(回答)サーバ<。--------- <、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、--
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
上のダイヤグラムで、NASは要求を生成して、それをProxy1に送ります。 Proxy1は要求をProxy2に転送します、そして、Proxy2はホームServerに要求を転送します。ホームServerは回答を生成して、それをProxy2に送ります。 Proxy2は回答を受け取って、それが送った要求にそれを合わせて、回答をProxy1に送ります。 Proxy1
Aboba & Vollbrecht Informational [Page 5] RFC 2607 Proxy Chaining and Policy in Roaming June 1999
1999年6月に移動することにおけるAboba&Vollbrechtの情報[5ページ]のRFC2607プロキシ推論と方針
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に送ります。 このモデルはAccess RequestsとAccounting Requestsを含むすべての要求に適用します。
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を除いて、最初にホームServerによって開始されたReplyパケットを受けていなくて、以下で説明されたケース、SHOULD NOTの上のダイヤグラムによるProxy2などのプロキシサーバはReplyパケットをProxy1に送ります。2つの例外はプロキシがいつセクション5.1で説明されるように方針を実施しているか、そして、プロキシがいつ会計店(同じくらい用意してと同じくらい前方)として務めているかということです、セクション5.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.
[3]で説明されたRADIUSプロトコルは終わりから終わりへのセキュリティー・サービスに備えません、保全、反復操作による保護、認証または秘密性を含んでいて。 セキュリティ問題部で注意されるように、この省略はプロキシ推論システムの中のいくつかの警備上の問題をもたらします。
5.1. Policy implementation
5.1. 政策の実施
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-要求に答えるかもしれません。 直接Access-要求に答えるとき、プロキシはAccess-廃棄物かAccess-挑戦パケットで返答しなければなりません。 プロキシが直接返答してはいけない、Access受け入れてください。 この例はプロキシがゴールデンアワーの間に特定の分野からすべての接続を拒否する時でしょう。 この場合ホームサーバが決して受信されない、Access第要求。 この状況は以下に示されます:
(request) (request)
NAS ----------> Proxy1 ----------> Proxy2 Home
(reply) (reply) Server
<--------- <---------
(要求します) (要求)NAS---------->Proxy1---------->Proxy2ホーム(回答)(回答)サーバ<。--------- <、-、-、-、-、-、-、-、--
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.
また、プロキシはホームサーバによって受け入れられたRequestについてRejectに決めるかもしれません。これはホームサーバによって返された属性のセットに基づくことができました。この場合Proxy SHOULDはAccess-廃棄物をNASに送ります、そして、Acct-状態タイプとのAccounting-要求はホームサーバへのプロキシ停止(6)と等しいです。これで、ホームサーバは、それが承認したセッションが川下でプロキシによって否定されたのを知っています。 しかしながら、プロキシはAccess-廃棄物をプロキシかホームサーバから後にAccess受け入れている受信に送ってはいけません。
Aboba & Vollbrecht Informational [Page 6] RFC 2607 Proxy Chaining and Policy in Roaming June 1999
1999年6月に移動することにおけるAboba&Vollbrechtの情報[6ページ]のRFC2607プロキシ推論と方針
(Access-Req) (Access-Req) (Access-Req)
NAS ----------> Proxy1 ----------> Proxy2 ----------> Home
(Access-Reject) (Access-Accept) (Access-Accept) Server
<--------- <--------- <---------
(AcctPxStop) (AcctPxStop)
----------> ---------->
(アクセス-Req) (アクセス-Req)(アクセス-Req)NAS---------->Proxy1---------->Proxy2---------->ホーム(アクセス廃棄物)(アクセスして受け入れる)(アクセスして受け入れます)サーバ<。--------- <、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-- (AcctPxStop) (AcctPxStop) ---------->。---------->。
5.2. Accounting behavior
5.2. 会計の振舞い
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.
それは別のプロキシかホームServerからAccess-廃棄物を受けました。上で説明されて、直接Accessと共に受け入れて、同じその結果、会計帳簿が(受け入れられたセッション)が生成されることであるすべての場合では、どんなダイレクト回答も起こっていなくて、Access-要求でAccess受け入れるのが通り抜けたなら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.
プロキシを許容するために、入って来るAccounting-要求に以前にと合っているのは、Access-要求を扱って、Access受け入れます、同じ分野経路に沿ったAccounting-要求が認証/承認で旅行したプロキシSHOULDルート。 これが、会計パケットが必ず同じ経路を旅行するのを含意しないことに注意してください、マシンごとに認証/承認パケットのように。 これはプロキシが落ちたのが想像できるからですその結果、Accounting-要求は代替のサーバに送られる必要があるかもしれません。また、認証/承認と会計が分野の中で異なったサーバによって扱われるのが想像できます。
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.
先のAccess RequestsにAccounting Requestsを合わせるのにClass属性を使用できます。 また、ホームのServerと、プロキシと、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:
ホームサーバSHOULDが中でユニークなセッション識別子をClass属性に挿入する、Access受け入れてください、そして、Access挑戦してください。 プロキシとNASesは変更されていないClass属性を進めなければなりません。 NAS MUSTは特にAccounting-要求に関するその後の要求にClass属性を含んでいます。 イベントの系列は以下に示されます:
Aboba & Vollbrecht Informational [Page 7] RFC 2607 Proxy Chaining and Policy in Roaming June 1999
1999年6月に移動することにおけるAboba&Vollbrechtの情報[7ページ]のRFC2607プロキシ推論と方針
Authentication/Authorization
認証/承認
--------> --------> --------->
NAS Proxy1 Proxy2 Home (add class)
<-class-- <-class- <-class--
-------->。-------->。--------->NAS Proxy1 Proxy2ホーム(クラスを加える)の<-クラス(<-クラス<-クラス)
Accounting
会計
(Accounting-req) (Accounting-req) (Accounting-req)
w/class w/class w/class
NAS ----------> Proxy1 ----------> Proxy2 ----------> Home
(Accounting-reply) (Accounting-reply)(Accounting-reply) Server
<--------- <--------- <---------
(会計-req) クラスNASがあるクラスがあるクラスがある(会計-req)(会計-req)---------->Proxy1---------->Proxy2---------->ホーム(会計回答)(会計回答)(会計回答)サーバ<。--------- <、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、--
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.
会計には政策を実施する必要が全くないので、プロキシは経路の次のサーバにすべてのAccounting Requestsを送らなければなりません。 プロキシは、Accounting RequestがEnd Serverとすべての中間的サーバによって受け取られるのを保証しなければなりません。 プロキシは以下でこれをするかもしれません。 1) Replyを受けるまでAccounting Requestを「再-進め」ることへの責任を取る店ポイントとして上流のサーバから合っているReplyを受けるまで返信するか、または2ではなくAccounting Request) 芝居を転送します。
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.
合っている回答を受け取るまでプロキシが返信しないと、これはAccounting StartとStopメッセージが受信されているのを確実にして、ローミング関係経路に沿ったすべてのサーバで登録できることに注意してください。 サーバの1つが利用可能でないなら、操作は失敗するでしょう。 その結果、全体の会計トランザクションを、一体にして成功するか、または失敗して、その結果、原子であると言うことができます。
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つ以上のサーバが他のものが受け取る間会計データを受け取らないのは、可能です。 会計作業は、一体にして成功もしませんし、失敗もしないで、したがって、原子ではありません。 その結果、ローミングパートナーが彼らの監査ログを和解させるのは、可能でないかもしれません、詐欺の初めの新しい機会。 それらが受け取られているので、店とフォワードが実装されるところでは、進めて、川下のサーバがタイムリーな方法でそれらを受けるように、Accounting Requests SHOULDでは、してください。
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.
ケースがプロキシがAccountingパケットを1台以上のシステムに送る必要があるところにあることに注意してください。 例えば、それはNASの場合で適切な会計を考慮するために停止しています、缶がそれが進めるすべての分野へのAcct-状態タイプ=会計が下にあるAccounting-要求(8)を送るプロキシ。 また、順番に、これらのプロキシは彼らの関連分野へパケットをあふれさせるでしょう。
Aboba & Vollbrecht Informational [Page 8] RFC 2607 Proxy Chaining and Policy in Roaming June 1999
1999年6月に移動することにおけるAboba&Vollbrechtの情報[8ページ]のRFC2607プロキシ推論と方針
6. References
6. 参照
[1] Aboba, B., Lu J., Alsop J., Ding J. and W. Wang, "Review of
Roaming Implementations", RFC 2194, September 1997.
[1]AbobaとB.とLu J.とAlsop J.と鐘の音J.とW.ワング、「ローミング実装のレビュー」、RFC2194、1997年9月。
[2] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming
Protocols", RFC 2477, January 1999.
[2]AbobaとB.とG.ゾルン、「ローミングプロトコルを評価する評価基準」、RFC2477、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.ウィレンス、「ユーザサービス(半径)におけるリモート認証ダイヤル」RFC2138(1997年4月)。
[4] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
[4]Rigney、C.、「半径会計」、RFC2139、1997年4月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[6] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
2486, January 1999.
[6]AbobaとB.とM.用務員、「ネットワークアクセス識別子」、RFC2486、1999年1月。
7. Security Considerations
7. セキュリティ問題
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
データReplay攻撃がConnectionハイジャックFraudulent会計であることを説明するパスワードTheftと変更のTheftを編集するメッセージ編集Attribute
7.1. Message editing
7.1. メッセージ編集
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.
共有秘密キーの使用で、異なったドメインで働いているプロキシに、信頼関係を確立するのは可能です。 しかしながら、ホップごとのセキュリティだけが利用可能であるなら、信頼されていないプロキシは多くの介入者攻撃を犯すことができます。 これらはメッセージの変更を含んでいます。
Aboba & Vollbrecht Informational [Page 9] RFC 2607 Proxy Chaining and Policy in Roaming June 1999
1999年6月に移動することにおけるAboba&Vollbrechtの情報[9ページ]のRFC2607プロキシ推論と方針
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受け入れてください、終わりから終わりへの保全保護がなければ、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.
また、認証ログエントリーで対応する会計ログエントリーなしで. これがそうするホームサーバからAccess受け入れている結果を受けた後にプロキシがAccess-廃棄物をNASに送ることができることに注意してください。 そして、プロキシがプロキシAcct状態タイプ=停止(6)とのAccounting-要求をホームサーバに送らないで、ホームサーバが食い違いが会計パケットの政策の実施か損失のためであるかを決定する方法が全くないでしょう。 プロキシしたがって、Acct-状態タイプの使用=停止には、ローミングシステムをデバッグするのにおいて価値があることができます。
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-状態タイプ=停止メッセージを受け入れてください。 このメッセージは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 retransmissionでNASによって追い立てられます。 したがって、ホームサーバが承認を受けない、Access受け入れて、その結果、応答が光栄に思っていないのを知る方法を全く持っていないでしょう。
7.2. Attribute editing
7.2. 属性編集
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.
[3]で定義されるRADIUSは終わりから終わりへのセキュリティか能力交渉に備えません。 その結果、ホームサーバがしっかりと互いに許容している構成を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
例えば、EAP MD5と共に認証するクライアントかPAPを引き起こすようにEAP属性を取り除くか、または変更するかもしれません、より強い認証方法の代わりに。 あるいはまた、暗号化を取り除くか、凶暴なトンネルサーバにトンネルを向け直すか、またはそうでなければ、セキュリティを少なくするようにトンネル属性を取り除くか、または変更するかもしれません。
Aboba & Vollbrecht Informational [Page 10] RFC 2607 Proxy Chaining and Policy in Roaming June 1999
1999年6月に移動することにおけるAboba&Vollbrechtの情報[10ページ]のRFC2607プロキシ推論と方針
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.
クライアントに提供します。 Accounting-要求に属性に対してAccess受け入れている属性をたとえるのによる事実を含んだ後に、要求されて容認されたサービスの間のミスマッチは検出可能であるだけであるかもしれません。 しかしながら、終わりから終わりへのセキュリティー・サービスがなければ、凶暴なプロキシが証拠を隠すのは、可能です。
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.
あらかじめ与えられた属性が編集可能であるかどうか決定するのが可能でないので、メカニズムは、「非編集可能な」属性の変更を検出するのに送付者がどの属性が編集可能であるか、そして、どれがないかを示すのを許容するために提供されて、受信機のために必要があります。 終わりから終わりへのセキュリティの実装を通して、保全で保護された属性の権限のない追加、削除、または変更を検出するのは可能であるかもしれません。 しかしながら、それはまだ凶暴なプロキシが保全によって保護されなかった属性を加えるか、削除するか、または変更するのにおいて可能な状態でそうしているでしょう。 そのような属性がその後の充電に影響を及ぼすなら、詐欺の可能性は残っているでしょう。
7.3. Theft of passwords
7.3. パスワードの窃盗
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とホームサーバの間の経路に沿った各プロキシはcleartextパスワードに近づく手段を持つでしょう。 多くの事情では、これは容認できないセキュリティリスクを表します。
7.4. Theft and modification of accounting data
7.4. 会計データの窃盗と変更
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
通常ローミングシステムでは、ローミング関係経路に沿った参加者各位に会計パケットを提供します、彼らがその後のインボイスを監査するのを許容するために。 保全保護か秘密性を含んでいて、[3]で説明されるRADIUSは終わりから終わりへのセキュリティー・サービスに備えません。 終わりから終わりへの保全保護がなければ、プロキシが会計パケットかセッション記録を変更するのは、可能です。 終わりから終わりへの秘密性、会計なしで
Aboba & Vollbrecht Informational [Page 11] RFC 2607 Proxy Chaining and Policy in Roaming June 1999
1999年6月に移動することにおけるAboba&Vollbrechtの情報[11ページ]のRFC2607プロキシ推論と方針
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.
データはプロキシにアクセス可能になるでしょう。 しかしながら、目的が単にワイヤに関する会計データについて詮索するのを防ぐことであるなら、IPSEC ESPを使用できます。
7.5. Replay attacks
7.5. 反射攻撃
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 Challenge/応答組をキャプチャしたものでなければならないというわけではありません。
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.
[3]で説明されるRADIUSが反射攻撃に被害を受け易い間、ローミングがなければ、脅威はホームサーバのドメインで働いているプロキシに制限されます。 ローミングで、ホームサーバに達することができるどんなプロキシもそのような攻撃を仕掛けることができます。
7.6. Connection hijacking
7.6. 接続ハイジャック
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とホームサーバとの会話にパケットを注ぐのを試みます。Access回答とAccess-挑戦パケットだけが認証されるので、[3]で説明されるRADIUSはそのような攻撃に被害を受け易いです。
7.7. Fraudulent accounting
7.7. 詐欺的な会計
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.
和解をより簡単にするように、ローミングインクルードa Classにかかわるサーバは、中で家では、Access受け入れるのを結果と考えます。 Class属性は唯一セッションを特定します、認証ログエントリーが対応する会計パケットかセッション記録に合われているのを許容するために。
Aboba & Vollbrecht Informational [Page 12] RFC 2607 Proxy Chaining and Policy in Roaming June 1999
1999年6月に移動することにおけるAboba&Vollbrechtの情報[12ページ]のRFC2607プロキシ推論と方針
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.
プロキシ会計への店と前進のアプローチの実装でローミング関係経路のいくつかのシステムが他のシステムが得ない会計帳簿を受け取るのが可能になることに注意してください。 これは監査食い違いをもたらすことができます。 達成可能であるのが、そのような場合それについて確かめることであるということであるベストに関して、会計データは、認証ログに対してチェックすることによって、なくなっています。
8. Acknowledgments
8. 承認
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.
この問題スペースの役に立つ議論をサン・マイクロシステムズのパットCalhoun、Meritのコンピュ・サーブのマークBeadles、モーニングスターのアイドゥンEdguerビルBulley、およびShore.Netのスティーブン・P.クレインをありがとうございます。
Aboba & Vollbrecht Informational [Page 13] RFC 2607 Proxy Chaining and Policy in Roaming June 1999
1999年6月に移動することにおけるAboba&Vollbrechtの情報[13ページ]のRFC2607プロキシ推論と方針
9. Authors' Addresses
9. 作者のアドレス
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン 98052
Phone: 425-936-6605 EMail: bernarda@microsoft.com
以下に電話をしてください。 425-936-6605 メールしてください: bernarda@microsoft.com
John R. Vollbrecht Merit Network, Inc. 4251 Plymouth Rd. Ann Arbor, MI 48105-2785
ジョンR.Vollbrecht長所ネットワークInc.4251プリマス通り アナーバー、MI48105-2785
Phone: 313-763-1206 EMail: jrv@merit.edu
以下に電話をしてください。 313-763-1206 メールしてください: jrv@merit.edu
Aboba & Vollbrecht Informational [Page 14] RFC 2607 Proxy Chaining and Policy in Roaming June 1999
1999年6月に移動することにおけるAboba&Vollbrechtの情報[14ページ]のRFC2607プロキシ推論と方針
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Aboba & Vollbrecht Informational [Page 15]
Aboba&Vollbrecht情報です。[15ページ]
一覧
スポンサーリンク
