RFC3838 日本語訳
3838 Policy, Authorization, and Enforcement Requirements of the OpenPluggable Edge Services (OPES). A. Barbir, O. Batuner, A. Beck, T.Chan, H. Orman. August 2004. (Format: TXT=38739 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Barbir
Request for Comments: 3838 Nortel Networks
Category: Informational O. Batuner
Consultant
A. Beck
Lucent Technologies
T. Chan
Nokia
H. Orman
Purple Streak Development
August 2004
Barbirがコメントのために要求するワーキンググループA.をネットワークでつないでください: 3838 ノーテルはカテゴリをネットワークでつなぎます: 情報のO.BatunerコンサルタントのA.べックルーセントテクノロジーズのT.チェンのノキアH.Ormanは一続きの開発2004年8月に紫色にします。
Policy, Authorization, and Enforcement Requirements
of the Open Pluggable Edge Services (OPES)
開いているPluggable縁のサービスの方針、承認、および実施要件(作品)
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 (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This document describes policy, authorization, and enforcement requirements for the selection of the services to be applied to a given Open Pluggable Edge Services (OPES) flow.
このドキュメントは方針、承認、およびサービスの品揃えが与えられたオープンPluggable Edge Services(作品)流動に適用されるという実施要件について説明します。
Barbir, et al. Informational [Page 1] RFC 3838 OPES Policy Requirements August 2004
Barbir、他 [1ページ]情報のRFC3838作品方針要件2004年8月
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Policy Architecture . . . . . . . . . . . . . . . . . . . . . 4
3.1. Policy Components and Functions . . . . . . . . . . . . 4
3.2. Requirements for Policy Decision Points. . . . . . . . . 5
3.3. Requirements for Policy Enforcement Points . . . . . . . 5
4. Requirements for Interfaces . . . . . . . . . . . . . . . . . 6
4.1. Service Bindings Requirements . . . . . . . . . . . . . 7
4.1.1. Environment Variables . . . . . . . . . . . . . 7
4.1.2. Requirements for Using State Information . . . . 8
4.1.3. Requirements for Passing Information Between
Services . . . . . . . . . . . . . . . . . . . . 8
4.2. Requirements for Rule and Rules Management . . . . . . . 8
4.2.1. Requirements for Rule Providers . . . . . . . . 8
4.2.2. Requirements for Rule Formats and Protocols . . 9
4.2.3. Requirements for Rule Conditions . . . . . . . . 9
4.2.4. Requirements for Rule Actions . . . . . . . . . 9
4.3. Requirements for Policy Expression . . . . . . . . . . . 10
5. Authentication of Principals and Authorization of Services . . 10
5.1. End users, Publishers and Other Considerations . . . . . 11
5.1.1. Considerations for End Users . . . . . . . . . . 11
5.1.2. Considerations for Publishing Sites. . . . . . . 12
5.1.3. Other Considerations . . . . . . . . . . . . . . 12
5.2. Authentication . . . . . . . . . . . . . . . . . . . . . 12
5.3. Authorization . . . . . . . . . . . . . . . . . . . . . 13
5.4. Integrity and Encryption . . . . . . . . . . . . . . . . 14
5.4.1. Integrity and Confidentiality of Authentication
and Requests/Responses for Service . . . . . . . 14
5.4.2. Integrity and Confidentiality of Application
Content . . . . . . . . . . . . . . . . . . . . 14
5.5. Privacy. . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 方針アーキテクチャ. . . . . . . . . . . . . . . . . . . . . 4 3.1。 方針コンポーネントと機能. . . . . . . . . . . . 4 3.2。 政策決定ポイントのための要件。 . . . . . . . . 5 3.3. 方針実施ポイント. . . . . . . 5 4のための要件。 インタフェース. . . . . . . . . . . . . . . . . 6 4.1のための要件。 結合要件. . . . . . . . . . . . . 7 4.1.1を修理してください。 環境変数. . . . . . . . . . . . . 7 4.1.2。 使用のための要件は情報. . . . 8 4.1.3を述べます。 サービス. . . . . . . . . . . . . . . . . . . . 8 4.2の間で情報を通過するための要件。 規則と規則管理. . . . . . . 8 4.2.1のための要件。 規則プロバイダー. . . . . . . . 8 4.2.2のための要件。 規則形式とプロトコル. . 9 4.2.3のための要件。 規則状態. . . . . . . . 9 4.2.4のための要件。 規則動作. . . . . . . . . 9 4.3のための要件。 方針式. . . . . . . . . . . 10 5のための要件。 主体の認証とサービス. . 10 5.1の承認。 エンドユーザ、Publishers、およびOther Considerations. . . . . 11 5.1.1。 エンドユーザ. . . . . . . . . . 11 5.1.2のための問題。 サイトを発表するための問題。 . . . . . . 12 5.1.3. 他の問題. . . . . . . . . . . . . . 12 5.2。 認証. . . . . . . . . . . . . . . . . . . . . 12 5.3。 承認. . . . . . . . . . . . . . . . . . . . . 13 5.4。 保全と暗号化. . . . . . . . . . . . . . . . 14 5.4.1。 サービス. . . . . . . 14 5.4.2のための認証と要求/応答の保全と秘密性。 アプリケーション内容. . . . . . . . . . . . . . . . . . . . 14 5.5の保全と秘密性。 プライバシー。 . . . . . . . . . . . . . . . . . . . . . . . . 14 6. セキュリティ問題. . . . . . . . . . . . . . . . . . . 15 7。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1。 引用規格. . . . . . . . . . . . . . . . . . 15 7.2。 有益な参照. . . . . . . . . . . . . . . . . 15 8。 承認. . . . . . . . . . . . . . . . . . . . . . . 16 9。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 16 10。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 17
Barbir, et al. Informational [Page 2] RFC 3838 OPES Policy Requirements August 2004
Barbir、他 [2ページ]情報のRFC3838作品方針要件2004年8月
1. Introduction
1. 序論
The Open Pluggable Edge Services (OPES) [1] architecture enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer. The OPES processor can distribute the responsibility of service execution by communicating and collaborating with one or more remote callout servers.
オープンPluggable Edge Services(作品)[1]アーキテクチャは情報提供業者と、データ消費者と、ゼロの間のアプリケーション・サービス(作品サービス)か、より多くの作品プロセッサを協力して可能にします。 考慮しているアプリケーション・サービスは、情報提供業者とデータ消費者の間で交換されたアプリケーションレベルメッセージを、分析して、ことによると変えます。 作品プロセッサは、1つ以上のリモートcalloutサーバを伝えて、協力することによって、サービス実行の責任を分配できます。
The execution of such services is governed by a set of rules installed on the OPES processor. The rule evaluation can trigger the execution of service applications local to the OPES processor or on a remote callout server.
そのようなサービスの実行は作品プロセッサにインストールされた1セットの規則で治められます。 規則評価は作品プロセッサ、または、リモートcalloutサーバの上のローカルのサービスアプリケーションの実行の引き金となることができます。
Policies express the goals of an OPES processor as a set of rules used to administer, manage, and control access to resources. The requirements in this document govern the behavior of OPES entities in determining which of the available services are to be applied to a given message, if any.
1セットの規則がリソースへのアクセスを管理して、管理して、以前はよく制御していたとき、方針は作品プロセッサの目標を言い表します。 要件は本書では営業品目のどれがもしあれば与えられたメッセージに適用されるかことであるかを決定することにおける、作品実体の振舞いを治めます。
The scope of OPES policies described in this document are limited to those that describe which services to call and, if appropriate, with what parameters. These policies do not include those that prescribe the behavior of the called services. It is desirable to enable a common management framework for specifying policies for both the calling of and the behavior of a service. The integration of such a function is the domain of policy administration user interaction applications.
そして、本書では説明された作品方針の範囲がどのサービスを呼んだらよいかを説明するものに制限される、どんなパラメタで適切であるかなら。 これらの方針は呼ばれたサービスの振舞いを定めるものを含んでいません。 それは、両方の呼ぶ指定方針のために一般的な管理フレームワークを可能にするのにおいて望ましくて、サービスの振舞いです。 そのような機能の統合は方針管理ユーザ相互作用アプリケーションのドメインです。
The document is organized as follows: Section 2 considers policy framework. Section 3 discusses requirements for interfaces, while section 4 examines authentication of principals and authorization of services.
ドキュメントは以下の通りまとめられます: セクション2は方針フレームワークを考えます。 セクション3はインタフェースのための要件について論じますが、セクション4は主体の認証とサービスの承認を調べます。
2. Terminology
2. 用語
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [4]. When used with the normative meanings, these keywords will be all uppercase. Occurrences of these words in lowercase comprise normal prose usage, with no normative implications.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[4]で説明されるように本書では解釈されることであるべきですか? 標準の意味と共に使用されると、これらのキーワードはすべて大文字するようになるでしょう。 コネが小文字で印刷するこれらの単語の発生は標準の含意なしで正常な散文用法を包括します。
Barbir, et al. Informational [Page 3] RFC 3838 OPES Policy Requirements August 2004
Barbir、他 [3ページ]情報のRFC3838作品方針要件2004年8月
3. Policy Architecture
3. 方針アーキテクチャ
This section describes the architectural policy decomposition requirements. It also describes the requirements for the interfaces between the policy components. Many of the rules here were determined under the influence of RFC 3238 [2].
このセクションは建築方針分解要件について説明します。 また、それは方針コンポーネントの間のインタフェースのための要件について説明します。 ここの規則の多くがRFC3238[2]の影響を受けて決定していました。
3.1. Policy Components and Functions
3.1. 方針コンポーネントと機能
The policy functions are decomposed into three components: a Rule Author, a Policy Decision Point (PDP) [6], and a Policy Enforcement Point (PEP) [6]. The Rule Author provides the rules to be used by an OPES entity. These rules control the invocation of services on behalf of the rule author. The PDP and the PEP interpret the collected rules and appropriately enforce them. The decomposition is illustrated in Figure 1.
方針機能は3つのコンポーネントに分解されます: 規則作者、政策決定ポイント(PDP)[6]、および方針実施は(気力)[6]を指します。 Rule Authorは、作品実体によって使用されるために規則を提供します。 これらの規則は規則作者を代表してサービスの実施を制御します。 PDPとPEPは集まっている規則を解釈して、適切にそれらを実施します。 分解は図1で例証されます。
+--------+ +--------+
| Rule | | Rule |
| Author | ... | Author |
+--------+ +--------+
| |
| |
| +----------+ |
| | Policy | | <- PDP Interface
+--------->| Decision |<----------+
| Point |
+----------+
| ^
| |
| | <- PEP Interface
| |
V |
+--------------+ ...
---> | Policy | --->
| Enforcement | Data Traffic
<--- | Point | <---
+--------------+
+--------+ +--------+ | 規則| | 規則| | 作者| ... | 作者| +--------+ +--------+ | | | | | +----------+ | | | 方針| | <。 PDPインタフェース+--------->| 決定| <、-、-、-、-、-、-、-、-、--+ | ポイント| +----------+ | ^ | | | | <。 気力インタフェース| | V| +--------------+ ... --->| 方針| --->| 実施| データ通信量<。--- | ポイント| <-- +--------------+
Figure 1: Policy Components
図1: 方針コンポーネント
The decomposition of policy control into a PDP and a PEP permit the offloading of some tasks to an administrative service that may be located on a server separate from the real-time enforcement services of the PEP that reside on the OPES processor.
PDPへの方針コントロールの分解とPEPは作品プロセッサの上に住んでいるPEPのリアルタイムの実施サービスから別々のサーバに位置するかもしれない行政サービスにいくつかのタスクの陸揚を可能にします。
Barbir, et al. Informational [Page 4] RFC 3838 OPES Policy Requirements August 2004
Barbir、他 [4ページ]情報のRFC3838作品方針要件2004年8月
The PDP provides for the authentication and authorization of rule authors and the validation and compilation of rules.
PDPは規則の規則作者の認証と承認、合法化、および編集に備えます。
The PEP resides in the data filter where the data from an OPES flow is evaluated against the compiled rules and appropriate calls to the requested services are performed.
PEPは作品流動からのデータがコンパイルされた規則に対して評価されて、要求されたサービスへの適切な呼び出しが実行されるデータフィルタに住んでいます。
Interfaces between these architectural components are points of interoperability. The interface between rule authors and the policy decision points (PDP Interface) MUST use the format that may result from the requirements as described in this document.
これらの建築構成の間のインタフェースはポイントの相互運用性です。 規則作者と政策決定ポイント(PDP Interface)とのインタフェースは本書では説明されるように要件から生じるかもしれない形式を使用しなければなりません。
The interface between the policy decision points and the policy enforcement points (PEP Interface) can be internal to a specific vendor implementation of an OPES processor. Implementations MUST use standard interface only if the PDP and the PEP reside on different OPES processors.
政策決定ポイントと方針実施ポイント(PEP Interface)とのインタフェースは作品プロセッサの特定のベンダー実装に内部である場合があります。 PDPとPEPが異なった作品プロセッサの上に住んでいる場合にだけ、実装は標準インターフェースを使用しなければなりません。
3.2. Requirements for Policy Decision Points
3.2. 政策決定ポイントのための要件
The Policy Decision Point is essentially a policy compiler. The PDP MUST be a service that provides administrative support to the enforcement points. The PDP service MUST authenticate the rule authors.
Policy Decision Pointは本質的には方針コンパイラです。 PDP MUST、管理サポートを実施ポイントに提供するサービスになってください。 PDPサービスは規則作者を認証しなければなりません。
The PDP MUST verify that the specified rules are within the scope of the rule authors authority. The PDP MUST be a component of the OPES Administration Authority.
PDP MUSTは、指定された規則が中では、規則の範囲が権威を書くということであることを確かめます。 PDP MUST、作品政権Authorityの部品になってください。
3.3. Requirements for Policy Enforcement Points
3.3. 方針実施ポイントのための要件
In the OPES architecture, the data filter represents a Policy Enforcement point (PEP). At this point, data from an OPES flow is evaluated against the compiled rules, and appropriate calls to the requested services are performed.
作品アーキテクチャで、データフィルタはPolicy Enforcementポイント(PEP)を表します。 ここに、作品流動からのデータはコンパイルされた規則に対して評価されます、そして、要求されたサービスへの適切な呼び出しは実行されます。
In the PEP rules MAY chain actions together, where a series of services to be called are specified. Implementation MUST ensure the passing of information from one called service to another. Implementation MUST NOT prohibit the re-evaluation of a message to determine if another service or set of services should be called.
PEPでは、呼ばれる一連のサービスが指定されるところで規則は動作を一緒にチェーニングするかもしれません。 実装は別のものに対するサービスと呼ばれる1からの情報の通過を確実にしなければなりません。 実装はサービスかもうの1セットのサービスが呼ばれるべきであるかどうか決定するメッセージの再評価を禁止してはいけません。
The execution of an action (i.e., the triggering of a rule) may lead to the modification of message property values. For example, an OPES service that under some circumstances converts JPEG images to GIF images modifies the content type of the requested web object.
動作(すなわち、規則の引き金となる)の実行はメッセージ特性の値の変更につながるかもしれません。 例えば、いくつかの状況でJPEGイメージをGIFイメージに変換する作品サービスは要求されたウェブオブジェクトのcontent typeを変更します。
Barbir, et al. Informational [Page 5] RFC 3838 OPES Policy Requirements August 2004
Barbir、他 [5ページ]情報のRFC3838作品方針要件2004年8月
Such modification of message property values may change the behavior of subsequently performed OPES actions. The data filter SHOULD act on matched rules before it evaluates subsequent rules. Multiple matched rules can be triggered simultaneously if the data filter can determine in advance that there are no side effects from the execution of any specific rule.
メッセージ特性の値のそのような変更は次に実行された作品動作の振舞いを変えるかもしれません。 その後の規則を評価する前にSHOULDが影響するデータフィルタは規則に合っていました。 データフィルタが、あらかじめどんな特定の規則の実行からの副作用も全くないことを決定できるなら、同時に、複数の取り組んでいる規則を引き起こすことができます。
A data filter MAY evaluate messages several times in the course of handling an OPES flow. The rule processing points MAY be defined by administratively defined names. The definition of such names can serve as a selector for policy rules to determine the applicability of a rule or a set of rules at each processing point.
作品流動を扱うことの間にデータフィルタは何度かメッセージを評価するかもしれません。 規則処理ポイントは行政上定義された名前によって定義されるかもしれません。 方針のためのセレクタがそれぞれの処理ポイントで規則の適用性か1セットの規則を決定するために統治されるようにそのような名前の定義は役立つことができます。
Policy roles ([5] and [6]) SHOULD be used where they aid in the development of the OPES policy model.
方針役割([5]と[6])SHOULD、それらが作品政策モデルの進化で支援するところで使用されてください。
Figure 2 expresses a typical message data flow between a data consumer application, an OPES processor, and a data provider application. There are four commonly used processing points identified by the numbers 1 through 4.
図2はデータ消費者アプリケーションと、作品プロセッサと、情報提供業者アプリケーションの間の典型的なメッセージデータフローを言い表します。 No.1〜4によって特定された一般的に使用された4処理ポイントがあります。
+--------+ +-----------+ +---------+
| |<------|4 3|<------| |
| Data | | OPES | | Data |
|Consumer| | Processor | |Provider |
| Appl. |------>|1 2|------>| Appl. |
+--------+ +-----------+ +---------+
+--------+ +-----------+ +---------+ | | <、-、-、-、-、--、|4 3| <、-、-、-、-、--、|、|、| データ| | 作品| | データ| |消費者| | プロセッサ| |プロバイダー| | Appl。 |、-、-、-、-、--、>|1 2|、-、-、-、-、--、>| Appl。 | +--------+ +-----------+ +---------+
Figure 2: Processing Execution Points
図2: 処理実行ポイント
Any data filter (PEP) or any administrative (PDP) implementation MUST support the four rule processing points.
どんなデータフィルタ(PEP)かどんな管理(PDP)実装も、4定規が処理ポイントであるとサポートしなければなりません。
o Data Consumer Request handling role: This involves request
processing when received from a Data Consumer Application.
o OPES Processor Request handling role: This involves request
processing before forwarding to Data Provider Application.
o Data Provider Response handling role: This involves response
processing when forwarding to Data Consumer Application.
o OPES Processor Response handling role: This involves response
processing when forwarding to Data Consumer Application.
o データConsumer Request取り扱いの役割: 役割を扱うData Consumer Application o作品Processor Requestから受け取ると、これは要求処理にかかわります: Data Provider Response取り扱いの役割をData Provider Application oに送る前に、これは要求処理にかかわります: 作品Processor Response取り扱いの役割をData Consumer Application oに送るとき、これは応答処理にかかわります: Data Consumer Applicationに進めるとき、これは応答処理にかかわります。
4. Requirements for Interfaces
4. インタフェースのための要件
The interface between the policy system and OPES services needs to include the ability to pass system state information as well as the subject message.
方針システムと作品サービスとのインタフェースは、対象のメッセージと同様にシステム州の情報を通過する能力を含む必要があります。
Barbir, et al. Informational [Page 6] RFC 3838 OPES Policy Requirements August 2004
Barbir、他 [6ページ]情報のRFC3838作品方針要件2004年8月
4.1. Service Bindings Requirements
4.1. サービス結合要件
The invoked OPES services MUST be able to be specified in a location independent fashion. That is, the rule authors need not know and need not specify the instance of an OPES service in the rules.
呼び出された作品サービスは位置の独立しているファッションで指定できなければなりません。 すなわち、作者が必要とする規則は、知って、規則で作品サービスのインスタンスを指定しなければなりません。
The rule author SHOULD be able to identify the required service at the detail level that is appropriate for his or her needs. The rule author SHOULD be able to specify a type of service or be able to specify any service that fits a general category of service to be applied to its traffic.
規則はSHOULDを書きます。その人の必要性に、適切な詳細レベルで必要なサービスを特定できてください。 規則はSHOULDを書きます。一種のサービスを指定するか、またはトラフィックに適用されるために一般的なサービスのカテゴリに合うあらゆるサービスは指定できてください。
The binding of OPES service names to a specific service MAY be distributed between the PDP and the PEP. As rules are compiled and validated by the PDP, they MUST be resolved to a specific installations' set of homogeneous OPES service.
特定のサービスへの作品サービス名の結合はPDPとPEPの間に広げられるかもしれません。 規則がコンパイルされて、PDPによって有効にされて、特定のインストールの均質に作品サービスのセットにそれらを決議しなければなりません。
The selection of a specific instance MAY be postponed and left to PEP to select at either the rule installation time or at run time. To achieve interoperability, PEP MUST support resolving a generic name to a specific instance. It is possible to use services such as SLP or UDDI to resolve generic service names to specific OPES service instances.
特定のインスタンスの選択は、規則インストール時間かランタイムのときに選択するのがPEPに延期されて、残されるかもしれません。 相互運用性を達成するために、PEP MUSTは、決議が総称であると特定のインスタンスにサポートします。 特定の作品サービスインスタンスにジェネリックサービス名を決議するのにSLPかUDDIなどのサービスを利用するのは可能です。
The policy system MAY support dynamic discovery of service bindings. The rule author may not know specific service bindings, such as protocol and parameters, when a rule (as specified on the PDP Interface) is general in nature. The required binding information MUST be provided by the PDP and conveyed on the PEP Interface. A service description methodology such as WSDL [8] MUST be present in the policy system.
方針システムはサービス結合のダイナミックな発見をサポートするかもしれません。 規則作者は特定のサービス結合を知らないかもしれません、プロトコルやパラメタのように、規則(PDP Interfaceで指定されるように)が現実に一般的であるときに。 必要な拘束力がある情報をPDPによって提供されて、PEP Interfaceで伝えなければなりません。 WSDL[8]などのサービス記述方法論は方針システムに存在していなければなりません。
4.1.1. Environment Variables
4.1.1. 環境変数
There may be a need to define and support a means for maintaining state information that can be used in both condition evaluation and action execution. Depending on the execution environment, OPES services MAY have the freedom to define variables that are needed and use these variables to further define their service behavior without the data filter support.
状態評価と動作実行の両方で使用できる州の情報を保守するための手段を定義して、サポートする必要があるかもしれません。 実行環境によって、作品サービスにはデータフィルタサポートなしで彼らの使用挙動をさらに定義するのに必要である変数を定義して、これらの変数を使用する自由があるかもしれません。
Barbir, et al. Informational [Page 7] RFC 3838 OPES Policy Requirements August 2004
Barbir、他 [7ページ]情報のRFC3838作品方針要件2004年8月
4.1.2. Requirements for Using State Information
4.1.2. 州の情報を使用するための要件
Policy rules MAY specify that state information be used as part of the evaluation of the rules against a given message in an OPES flow. Thus, the policy system SHOULD support the maintenance of groups that can be used in evaluating rule conditions. Membership in such groups can be used as action triggers.
政策ルールは、与えられたメッセージに対して州の情報が規則の評価の一部として作品流動に使用されると指定するかもしれません。 したがって、方針システムSHOULDは規則状態を評価する際に使用できるグループのメインテナンスをサポートします。 動作引き金としてそのようなグループにおける会員資格を使用できます。
For example, an authorized site blocking service might conclude that a particular user shouldn't be permitted access to a certain web site. Rather than calling the service for each request sent by such a user, a rule might be created to determine whether a user is a member of blocked users and if a requested site is a member of blocked-sites, and then invoke a local blocking service to return an appropriate message to the user.
例えば、サービスを妨げる認可されたサイトは、ある一定のウェブサイトへのアクセスが特定のユーザに受入れられるべきでないと結論を下すかもしれません。 そのようなユーザによって送られた各要求のためのサービスを呼ぶよりむしろ、規則は、ユーザが妨げられたユーザのメンバーであるかどうかと、要求されたサイトが妨げられたサイトのメンバーであるかどうか決定して、次に、適切なメッセージをユーザに返すために地方のブロッキングサービスを呼び出すために作成されるかもしれません。
4.1.3. Requirements for Passing Information Between Services
4.1.3. サービスの間で情報を通過するための要件
Environment variables can be used to pass state information between services. For example, analysis of the request or modifications to the request may need to be captured as state information that can be passed to other services on the request path or to services on the response(s) associated with that request.
サービスの間で州の情報を通過するのに環境変数を使用できます。 例えば、要求への要求か変更の分析は、要求経路における他のサービス、または、その要求に関連している応答のサービスに通過できる州の情報としてキャプチャされる必要があるかもしれません。
In the PEP, there SHOULD be provisions to enable setting up variables when returning from a service call and passing variables to other called services based on policy.
PEPでは、そこでは、業務通話から戻るとき変数をセットアップする可能にする条項であり、変数を他に通過しているとサービスと呼ばれたSHOULDが方針を基礎づけました。
4.2. Requirements for Rule and Rules Management
4.2. 規則と規則管理のための要件
This section provides the requirements for rule management. The rules are divided into two groups. Some rules are provided by the data consumer application, and other rules are provided by the data provider application.
このセクションは規則管理のための要件を提供します。 規則は2つのグループに分割されます。 データ消費者アプリケーションでいくつかの規則を提供します、そして、情報提供業者アプリケーションで他の規則を提供します。
4.2.1. Requirements for Rule Providers
4.2.1. 規則プロバイダーのための要件
The requirements for rule providers are:
規則プロバイダーのための要件は以下の通りです。
o Rule providers MUST be authenticated and authorized for rules that
apply to their network role.
o Rule providers MUST NOT be able to specify rules that are NOT
within their scope of authority.
o Rule providers SHOULD be able to specify only what is needed for
their services.
o Compilation of rules from different sources MUST NOT lead to
execution of conflicting rules.
o The resolution of such rule conflicts is out of scope.
o o Ruleプロバイダーがさまざまな原因からの規則のo Compilationが闘争規則の実行に通じてはいけないということでない規則を指定できるはずがないという規則のために規則プロバイダーを認証されて、認可しなければなりません。それらのネットワークの役割に適用してください。それらの権威o RuleプロバイダーSHOULDの範囲の中では、彼らのサービスに必要であるものだけは指定できてください。○ 範囲の外にそのような規則闘争の解決があります。
Barbir, et al. Informational [Page 8] RFC 3838 OPES Policy Requirements August 2004
Barbir、他 [8ページ]情報のRFC3838作品方針要件2004年8月
o Rules are assumed to be static and applied to current network
state.
o 規則は、静的であると思われて、現在のネットワーク状態に適用されます。
4.2.2. Requirements for Rule Formats and Protocols
4.2.2. 規則形式とプロトコルのための要件
It is desirable to choose standard technologies like XML to specify the rule language format.
規則言語形式を指定するためにXMLのような標準の技術を選ぶのは望ましいです。
Rules need to be sent from the rule authors to the OPES administrative server for service authorization, rule validation, and compilation. The mechanisms for doing that are out of scope of the current work.
規則は、サービス承認、規則合法化、および編集のために規則作者から管理作品サーバに送られる必要があります。 執筆中の作品の範囲の外にそれをするためのメカニズムがあります。
Once the rules are authorized, validated, and compiled by the administrative server, the rules need to be sent to the OPES processor. The mechanisms for doing that are out of scope of the current work.
規則が管理サーバによっていったん認可されて、有効にされて、コンパイルされると、規則は、作品プロセッサに送られる必要があります。 執筆中の作品の範囲の外にそれをするためのメカニズムがあります。
4.2.3. Requirements for Rule Conditions
4.2.3. 規則状態のための要件
Rule conditions MUST be matched against attribute values of the encapsulated protocol as well as environment variable values. Attribute values of the encapsulated protocol include protocol header values and possibly also protocol body values.
規則状態は環境変数値と同様にカプセル化されたプロトコルの属性値に取り組ませなければなりません。 カプセル化されたプロトコルの属性値はプロトコルヘッダー値とことによるとまた、プロトコルボディー値を含んでいます。
Some OPES services may need to be invoked for all user requests or server responses, such as services with logging functionality, for example. The rule system SHOULD allow unconditional rules rather than requiring rule authors to specify rule conditions that are always true.
いくつかの作品サービスが、サービスなどのすべてのユーザ要求かサーバ応答のために例えば、伐採の機能性で呼び出される必要があるかもしれません。 規則作者がいつも本当の規則状態を指定するのが必要であるというよりも規則システムSHOULDはむしろ無条件の規則を許容します。
4.2.4. Requirements for Rule Actions
4.2.4. 規則動作のための要件
The rule system MUST allow for the specification of rule actions that are triggered if the conditions of a rule are met. Matched rules typically lead to the invocation of local or remote services. Rule actions MUST identify the OPES service that is to be executed for the current message request or response.
規則システムは規則に関する条件が満たされるなら引き起こされる規則動作の仕様を考慮しなければなりません。 取り組んでいる規則は地方かリモートにサービスの実施に通常つながります。 規則動作は現在のメッセージ要求か応答のために実行されることになっている作品サービスを特定しなければなりません。
Rule actions MAY contain run-time parameters which can be used to control the behavior of an OPES service. If specified, these parameters MUST be passed to the executed OPES service.
規則動作は作品サービスの振舞いを制御するのに使用できるラン・タイム・パラメータを含むかもしれません。 指定されるなら、実行された作品サービスにこれらのパラメタを通過しなければなりません。
Barbir, et al. Informational [Page 9] RFC 3838 OPES Policy Requirements August 2004
Barbir、他 [9ページ]情報のRFC3838作品方針要件2004年8月
4.3. Requirements for Policy Expression
4.3. 方針式のための要件
OPES processors MUST enforce policy requirements set by data consumers and/or data publishers in accordance with the architecture [1] and this document. They cannot do this consistently unless there are an unambiguous semantics and representation of the data elements mentioned in the policy. For example, this document mentions protection of user "identity" and "profile" information. If a user specifies that his identity must not be shared with other OPES administrative trust domains, and later discovers that his family name has been shared, he might complain. If he were told that "family names are not considered 'identities' by this site", he would probably feel that he had cause for complaint. Or, he might be told that when he selected "do not share identity" on a web form offered by the OPES service provider, that this only covered his login name, and that a different part of the form had to be filled out to protect the family name. A further breakdown can occur if the configuration information provided by such a web form gets translated into configuration elements given to an OPES processor, and those configuration elements are difficult for a software engineer to translate into policy enforcement. The data elements might have confusing names or be split into groupings that are difficult to relate to one another.
作品プロセッサはアーキテクチャ[1]とこのドキュメントによると、データ消費者、そして/または、データ出版社によって設定された方針要件を実施しなければなりません。 方針で言及されたデータ要素の明白な意味論と表現がない場合、彼らは一貫してこれができません。 例えば、このドキュメントはユーザ「アイデンティティ」と「プロフィール」情報の保護について言及します。 ユーザが、他の作品の管理信頼ドメインと彼のアイデンティティを共有してはいけないと指定して、後で彼の姓が共有されたと発見するなら、彼は不平を言うかもしれません。 彼が「姓はこのサイトによって'アイデンティティ'であると考えられません」と言われるなら、彼は苦情を言う十分な理由があったとたぶん感じるでしょうに。 または、彼は彼であるときに、それがウェブの「アイデンティティを共有しないでください」という作品サービスプロバイダーによって提供されたフォームを選択して、これが彼のログイン名をカバーしただけであり、形式の異なった一部分が姓を保護するために書き込まれなければならなかったと言われるかもしれません。 そのようなウェブフォームによって提供された設定情報が作品プロセッサに与えられた構成要素に翻訳されるなら、さらなる故障は起こることができます、そして、ソフトウェア技術者に、それらの構成要素は方針実施に翻訳するのが難しいです。 データ要素は、名前を混乱させるか、またはお互いに関連するのが難しい組分けに分けられたかもしれません。
The examples illustrate why the OPES policy MUST have definitions of data elements, their relationships, and how they relate to enforcement. These semantics of essential items do not require a separate protocol, but they MUST be agreed upon by all OPES service providers, and the users of OPES services MUST be assured that they have the ability to know their settings, to change them if the service provider policy allows the changes, and to have reasonable assurance that they are enforced with reasonable interpretations.
例は、データ要素の定義と、自分達の関係と、それらがなぜ作品方針でどう実施に関連しなければならないかを例証します。 すべての作品サービスプロバイダーがそれらに同意しなければなりません、そして、不可欠の項目のこれらの意味論は別々のプロトコルを必要としませんが、それらにはそれらの設定を知って、サービスプロバイダー方針が変化を許容するならそれらを変えて、それらが理に適った解釈で実施されるという手頃な保証を持つ能力があると作品サービスのユーザを確信しなければなりません。
The requirements for policy data elements in the OPES specification do not have to be all-inclusive, but they MUST cover the minimal set of elements that enable the policies that protect the data of end users and publishers.
作品仕様による方針データ要素のための要件はすべてを含む必要はありませんが、それらはエンドユーザと出版社に関するデータを保護する方針を可能にする要素の極小集合をカバーしなければなりません。
5. Authentication of Principals and Authorization of Services
5. 主体の認証とサービスの承認
This section considers the authorization and authentication of OPES services.
このセクションは作品サービスの承認と認証を考えます。
Barbir, et al. Informational [Page 10] RFC 3838 OPES Policy Requirements August 2004
Barbir、他 [10ページ]情報のRFC3838作品方針要件2004年8月
5.1. End Users, Publishers and Other Considerations
5.1. エンドユーザ、出版社、および他の問題
5.1.1. Considerations for End Users
5.1.1. エンドユーザのための問題
An OPES rule determines which attributes of traffic will trigger the application of OPES services. The author of the service can supply rules, but the author cannot supply the necessary part of the rule precondition that determines which network users will have the OPES services applied for them. This section discusses how users are identified in the rule preconditions, and how users can select and deselect OPES services for their traffic, how an OPES service provider SHOULD identify the users, and how they determine whether or not to add their service selection to an OPES enforcement point.
作品規則は、トラフィックのどの属性が作品サービスの応用の引き金となるかを決定します。 サービスの作者は規則を供給できますが、作者はどのネットワーク利用者がそれらのために作品サービスを適用させるかを決定する規則前提条件の必要な部分を供給できません。 このセクションはユーザが規則前提条件でどう特定されるか、そして、ユーザがどう選択できるか、そして、ユーザと、彼らが、作品実施ポイントに彼らのサービス選択を追加するかどうかどう決定するかを作品サービスプロバイダーSHOULDがどう特定するかというそれらのトラフィックのためのdeselect作品サービスについて論じます。
An OPES service provider MUST satisfy these major requirements:
作品サービスプロバイダーはこれらの主要な要件を満たさなければなりません:
o Allow all users to request addition, deletion, or blocking of OPES
services for their traffic (blocking means "do not use this
service for my traffic").
o Prevent untrusted users from causing OPES services to interfere
with the traffic of other users.
o Allow users to see their OPES service profiles and notify them of
changes.
o Keep a log of all profile activity for audit purposes.
o Adhere to a privacy policy guarding users' profiles.
o すべてのユーザにそれらのトラフィックのために作品サービスの追加、削除、またはブロッキングを要求させてください(ブロッキングは、「私のトラフィックにこのサービスを利用しないでください」と意味します)。作品サービスが彼らの作品サービスプロフィールを見て、変化o Keepについてそれらに通知するために他のユーザo Allowユーザのトラフィックを妨げることを引き起こすのからのすべてに関するログが活動の輪郭を描くo Preventの信頼されていないユーザはユーザのプロフィールを警備するプライバシーに関する方針に目的o Adhereを監査します。
The administrator of the PDP is a trusted party and can set policy for individuals or groups using out-of-band communication and configuration files. However, users MUST always be able to query the PDP in order to learn what rules apply to their traffic.
PDPの管理者は、バンドの外でコミュニケーションと構成ファイルを使用することで信じられたパーティーであり、個人かグループに方針を設定できます。 しかしながら、ユーザは、どんな規則がそれらのトラフィックに適用されるかを学ぶためにいつもPDPについて質問できなければなりません。
Rules can be deposited in the PDP with no precondition relating to network users. This is the way rules are packaged with an OPES service when it is delivered for installation. The PDP is responsible for binding identities to the rules and transmitting them to the PEP. The identity used by the PDP for policy decisions MUST be strictly mapped to the identity used by the PEP. Thus, if a user goes through an identification and authentication procedure with the PDP and is known by identity "A", and if the PEP uses IP addresses for identities, then the PDP MUST provide the PEP with a binding between "A" and A's current IP address.
どんな前提条件もネットワーク利用者に関連しなく、PDPに規則を預けることができます。 これはそれがインストールのために提供されるとき、規則が作品サービスでパッケージされる方法です。 PDPは規則への拘束力があるアイデンティティに責任があってそれらをPEPに伝えます。 厳密に政策決定にPDPによって使用されたアイデンティティをPEPによって使用されたアイデンティティに写像しなければなりません。 したがって、ユーザがPDPと共に識別と認証手順を執り行って、アイデンティティ「A」によって知られていて、気力がアイデンティティにIPアドレスを使用するなら、PDPは「A」とAの現在のIPアドレスの間で結合を気力に提供しなければなりません。
Barbir, et al. Informational [Page 11] RFC 3838 OPES Policy Requirements August 2004
Barbir、他 [11ページ]情報のRFC3838作品方針要件2004年8月
5.1.2. Considerations for Publishing Sites
5.1.2. サイトを発表するための問題
An OPES service provider acting on behalf of different publishing sites SHOULD keep all the above considerations in mind when implementing an OPES site. Because each publishing site may be represented by only a single identity, the authentication and authorization databases may be easier for the PEP to handle.
作品サイトを実装するとき、異なった出版サイトSHOULDを代表して行動する作品サービスプロバイダーはすべての上の問題を覚えておきます。 それぞれの出版サイトがただ一つのアイデンティティだけによって表されるかもしれないので、PEPには、認証と承認データベースは扱うのが、より簡単であるかもしれません。
5.1.3. Other Considerations
5.1.3. 他の問題
Authentication may be necessary between PDP's and PEP's, PEP's and callout servers, PEP's and other PEP's, and callout servers and other callout servers, for purposes of validating privacy policies. In any case where user data or traffic crosses trust domain boundaries, the originating trust domain SHOULD have a policy describing which other domains are trusted, and it SHOULD authenticate the domains and their policies before forwarding information.
認証がPDPと、PEPと、PEPと、calloutサーバと、PEPと、他のPEPのものと、calloutサーバと他のcalloutサーバの間で必要であるかもしれません、プライバシーに関する方針を有効にする目的のために。 利用者データかトラフィックが信頼ドメイン境界に交差するどんな場合でも、起因している信頼ドメインSHOULDはどの他のドメインが信じられるかを説明する方針、およびそれを持っています。SHOULDは推進情報の前にドメインとそれらの方針を認証します。
5.2. Authentication
5.2. 認証
When an individual selects (or deselects) an OPES service, the individual MUST be authenticated by the OPES service provider. This means that a binding between the user's communication channel and an identity known to the service provider is made in a secure manner. This SHOULD be done using a strong authentication method with a public key certificate for the user; this will be helpful in resolving later disputes. It is recommended that the service provider keep a log of all requests for OPES services. The service provider SHOULD use public key certificates to authenticate responses to requests.
個人が作品サービスを選択するとき(または、deselects)、作品サービスプロバイダーは個人を認証しなければなりません。 これは、安全な方法でユーザの通信チャネルとサービスプロバイダーにおいて知られているアイデンティティの間の結合をすることを意味します。 このSHOULD、ユーザのために公開鍵証明書で強い認証方法を使用し終わってください。 これは後の論争を解決する際に役立つでしょう。 サービスプロバイダーが作品サービスを求めるすべての要求に関するログを保つのは、お勧めです。 サービスプロバイダーSHOULDは、要求への応答を認証するのに公開鍵証明書を使用します。
The service provider may have trusted users who through explicit or implicit contract can assign, remove, or block OPES services for particular users. The trusted users MUST be authenticated before being allowed to take actions which will modify the policy base, and thus, the actions of the PEP's.
サービスプロバイダーは特定のユーザのために明白であるか暗黙の契約を通して作品サービスを割り当てるか、取り除くか、または妨げることができるユーザを信じたかもしれません。 方針ベースを変更する行動、およびその結果PEPの行動を取るのが許容される前に信じられたユーザを認証しなければなりません。
Because of the sensitivity of user profiles, the PEP Interface between the PEP and the PDP MUST use a secure transport protocol. The PEP's MUST adhere to the privacy preferences of the users.
ユーザ・プロファイルの感度のために、PEPとPDP MUSTの間のPEP Interfaceは安全なトランスポート・プロトコルを使用します。 PEPのものはユーザのプライバシー好みを固く守らなければなりません。
When an OPES service provider accepts an OPES service, there MUST be a unique name for the service provided by the entity publishing the service. Users MAY refer to the unique name when requesting a service. The unique name MUST be used when notifying users about their service profiles. PEP's MUST be aware of the unique name for each service that can be accessed from their domain. There MUST be a cryptographic binding between the unique name and the entity
作品サービスプロバイダーが作品サービスを受け入れるとき、サービスを発行する実体によって提供されたサービスのためのユニークな名前があるに違いありません。 サービスを要求するとき、ユーザはユニークな名前を示すかもしれません。 彼らのサービスプロフィールに関してユーザに通知するとき、ユニークな名前を使用しなければなりません。 それらのドメインからアクセスできる各サービスにおいて、PEPはユニークな名前を意識しているに違いありません。 ユニークな名前と実体の間には、暗号の結合があるに違いありません。
Barbir, et al. Informational [Page 12] RFC 3838 OPES Policy Requirements August 2004
Barbir、他 [12ページ]情報のRFC3838作品方針要件2004年8月
responsible for the functional behavior of the service, i.e., if it is a human language translating service, then the name of company that wrote the software SHOULD be bound to the unique name.
機能的なサービスの振舞いに責任があるので、すなわち、それであるなら、次に、サービスを翻訳する人間の言語、ソフトウェアを書いた会社名はSHOULDです。ユニークな名前に制限されてください。
5.3. Authorization
5.3. 承認
In addition to requesting or terminating specific services, users MAY block particular services, indicating that the services should not be applied to their traffic. The "block all OPES" directive MUST be supported on a per user basis.
特定のサービスを要求するか、または終えることに加えて、ユーザは特定のサービスを妨げるかもしれません、サービスがそれらのトラフィックに適用されるべきでないのを示して。 ユーザ基礎あたりのaで「すべての作品を妨げてください」という指示をサポートしなければなりません。
A response to a request for an OPES service can be positive or negative. Reasons for a negative response include "service unknown" or "service denied by PDP policy". Positive responses SHOULD include the identity of the requestor and the service and the type of request.
作品サービスを求める要求への応答は、肯定しているか、または否定している場合があります。 否定応答の理由は「サービス未知」か「PDP方針で否定されたサービス」を含んでいます。 積極的な応答SHOULDは要求の要請者のアイデンティティ、サービス、およびタイプを含んでいます。
As described in the OPES Architecture [1], requests for OPES services originate in either the end user or the publisher domain. The PDP bases its authorization decision on the requestor and the domain. There are some cases where the decision may be complicated.
作品Architecture[1]で説明されるように、作品サービスを求める要求はエンドユーザか出版社ドメインのどちらかで起こります。 PDPは承認決定を要請者とドメインに基礎づけます。 いくつかのケースが決定が複雑であるかもしれないところにあります。
o The end user has blocked a service, but a trusted user of the PDP
wants it applied anyway. In this case, the end user SHOULD
prevail, unless there are security or legal reasons to leave it in
place.
o The publisher and the end user are in the same domain. If the
publisher and end user are both clients of a PDP, can they make
requests that effect each other's processing? In this case, the
PDP MUST have policy rules naming the identities that are allowed
to set such rules.
o The publisher requests a service for an end user. In this case,
where the PDP and PEP are in the publisher's administrative
domain, the publisher has some way of identifying the end user and
his traffic, and the PDP MUST enable the PEP to enforce the
policy. This is allowed, but the PDP MUST use strong methods to
identify the user and his traffic. The user MUST be able to
request and receive information about the service profile that a
publisher site keeps about him.
o The end user requests a service specific to a publisher's identity
(e.g., nfl.com), but the publisher prohibits the service (e.g.,
through a "NO OPES" application header). As in the case above,
the publisher MUST be able to request and receive profile
information that a user keeps about a publisher.
o エンドユーザはサービスを妨げましたが、PDPの信じられたユーザはとにかくそれを適用して欲しいです。 この場合、エンドユーザSHOULDは行き渡っています、セキュリティか適所にそれを残す法律上の理由がない場合。○ 出版社とエンドユーザは同じドメインにいます。 出版社とエンドユーザがPDPの両方のクライアントであるなら、彼らは互いの処理に作用する要求をすることができますか? この場合、PDP MUSTには、そのような規則を設定できるアイデンティティを命名する政策ルールがあります。○ 出版社はエンドユーザのためにサービスを要求します。 この場合、PDPとPEPが出版社の管理ドメインにあるところに出版社はエンドユーザと彼のトラフィックを特定する何らかの方法を持っています、そして、PDP MUSTはPEPが方針を実施するのを可能にします。 これは許容されていますが、PDP MUSTはユーザと彼のトラフィックを特定する強いメソッドを使用します。 ユーザは、出版社サイトが彼に関して保管するサービスプロフィールの情報を要求して、受け取ることができなければなりません。○ エンドユーザは出版社のアイデンティティ(例えば、nfl.com)に特定のサービスを要求しますが、出版社はサービス(例えば、「いいえ作品」アプリケーションヘッダーを通した)を禁止します。 ケースのように、出版社は、ユーザが保つというプロフィール情報を要求して、上では、出版社に関して受け取ることができなければなりません。
In general, the PDP SHOULD keep its policy base in a manner that makes the decision procedure for all cases easy to understand.
一般に、PDP SHOULDはすべてのケースのための決定手順を分かり易くする方法で方針ベースを保ちます。
Barbir, et al. Informational [Page 13] RFC 3838 OPES Policy Requirements August 2004
Barbir、他 [13ページ]情報のRFC3838作品方針要件2004年8月
5.4. Integrity and Encryption
5.4. 保全と暗号化
5.4.1. Integrity and Confidentiality of Authentication and Requests/
Responses for Service
5.4.1. サービスのための認証と要求/応答の保全と秘密性
The requests and responses SHOULD be cryptographically tied to the identities of the requestor and responder, and the messages SHOULD NOT be alterable without detection. A certificate-based digital signature is strongly recommended as part of the authentication process. A binding between the request and response SHOULD be established using a well-founded cryptographic means, to show that the response is made in reply to a specific request.
要請者と応答者のアイデンティティに結ばれて、要求と応答SHOULDは暗号でそうであり、メッセージはSHOULD NOTです。検出なしで可変であってください。 証明書ベースのデジタル署名は認証過程の一部として強く推薦されます。 要求と応答SHOULDの間の結合がゆるぎない暗号の手段を使用することで確立されて、それを示しているために、特定の要求に対して応答をします。
5.4.2. Integrity and Confidentiality of Application Content
5.4.2. アプリケーション内容の保全と秘密性
As directed by the PEP, content will be transformed in whole or in part by OPES services. This means that end-to-end cryptographic protections cannot be used. This is probably acceptable for the vast majority of traffic, but in cases where a lesser form of content protection is desirable, hop-by-hop protections can be used instead. The requirements for such protections are:
PEPによって指示されるように、内容は全体か一部作品サービスで変えられるでしょう。 これは、終わりから終わりへの暗号の保護を使用できないことを意味します。 トラフィックのかなりの大部分において、これはたぶん許容できますが、より少ない形式の満足している保護が望ましい場合では、代わりにホップごとの保護を使用できます。 そのような保護のための要件は以下の通りです。
o Integrity using shared secrets MUST be used between all processing
points, end-to-end (i.e., the two ends of a "hop" MUST share a
secret, but the secret can be different between "hops"). The
processing points include the callout servers.
o Encryption can be requested separately, with the same secret
sharing requirement between "hops". When requested, encryption
applies to all processing points, including callout servers.
o The signal for integrity (and optionally encryption) MUST
originate from either the requestor (in which case it is applied
to the response as well) or the responder (in which case it covers
only the response).
o The shared secrets MUST be unique (to within a very large
probabilistic certainty) for each requestor/responder pair. This
helps to protect the privacy of end user data from insider attacks
or configuration errors while it transits the provider's network.
o すべての処理ポイントの間で共有秘密キーを使用する保全を使用しなければなりません、終わらせる終わり(すなわち、「ホップ」の2つの終わりが秘密を共有しなければなりませんが、秘密は「ホップ」の間で異なっている場合があります)。 処理ポイントはcalloutサーバを含んでいます。別々にo Encryptionを要求できます、「ホップ」の間には、同じ秘密の共有要件がある状態で。 要求されると、暗号化がcalloutサーバを含むポイントをすべて処理するのに○ 保全のための信号を適用する、(任意に、暗号化) それぞれに、ユニークな(非常に大きい確率的な確実性への)要請者/応答者が組でなければならなかったなら要請者(その場合、それはまた、応答に適用される)か応答者のどちらかから. ○ (その場合、それは応答だけをカバーしています)共有秘密キーを溯源しなければなりません。 これは、プロバイダーのネットワークを通過している間、インサイダー攻撃か構成誤りからエンドユーザデータのプライバシーを保護するのを助けます。
5.5. Privacy
5.5. プライバシー
The PDP MUST have a privacy policy regarding OPES data such as user profiles for services. Users MUST be able to limit the promulgation of their profile data and their identities.
PDP MUSTには、サービスのためのユーザ・プロファイルなどの作品データに関してプライバシーに関する方針があります。 ユーザは彼らのプロフィールデータと彼らのアイデンティティの発布を制限できなければなりません。
Supported limitations MUST include:
サポートしている制限は以下を含まなければなりません。
o The ability to prevent Identity from being given to callout
servers.
o Identityがcalloutサーバに与えられているのを防ぐ能力。
Barbir, et al. Informational [Page 14] RFC 3838 OPES Policy Requirements August 2004
Barbir、他 [14ページ]情報のRFC3838作品方針要件2004年8月
o The ability to prevent Profile information from being shared.
o The ability to prevent Traffic data from being sent to callout
servers run by third parties.
o The ability to prevent Traffic from particular sites from being
given to OPES callout servers.
o 共有されるのからの. ○ Trafficデータを防ぐ能力がcalloutサーバに送るので第三者oで特定のサイトからTrafficを防ぐ能力を実行するというProfile情報が作品calloutサーバに与えられているのを防ぐ能力。
When an OPES service is provided by a third-party, it MUST have a privacy policy and identify itself to upstream and downstream parties, telling them how to access its privacy policy. A mechanism is needed to specify these preferences and a protocol to distribute them (see section 3.3).
作品サービスが第三者によって提供されるとき、上流の、そして、川下のパーティーにプライバシーに関する方針を持って、それ自体を特定しなければなりません、プライバシーに関する方針にアクセスする方法を彼らに教えて。 メカニズムが、それらを分配するためにこれらの好みとプロトコルを指定するのに必要です(セクション3.3を見てください)。
6. Security Considerations
6. セキュリティ問題
This document discusses policy, authorization and enforcement requirements of OPES. In [3] multiple security and privacy issues related to the OPES services are discussed.
このドキュメントは作品の方針、承認、および実施要件について議論します。 [3] 複数のセキュリティと関連するプライバシーの問題では、作品サービスについて議論します。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[1] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An
Architecture for Open Pluggable Edge Services (OPES)", RFC 3835,
August 2004.
[1]Barbir、A.、ペンノ、R.、チェン、R.、ホフマン、M.、およびH.Orman、「開いているPluggable縁のサービスのためのアーキテクチャ(作品)」、RFC3835(2004年8月)。
[2] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC 3238,
January 2002.
[2] フロイドとS.とL.Daigle、「開いているPluggable縁のサービスのためのIAB建築するのと方針問題」、RFC3238、2002年1月。
[3] Barbir, A., Batuner, O., Srinivas, B., Hofmann, M., and H.
Orman, "Security Threats and Risks for Open Pluggable Edge
Services (OPES)", RFC 3837, August 2004.
[3] Barbir、A.、Batuner、O.、Srinivas、B.、ホフマン、M.、およびH.Orman、「開いているPluggableのための軍事的脅威とリスクはサービス(作品)を斜めに進みます」、RFC3837、2004年8月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[5] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen,
"Policy Core Information Model -- Version 1 Specification", RFC
3060, February 2001.
[5] ムーア、B.、Ellesson、E.、Strassner、J.、およびA.Westerinen、「方針コア情報はモデル化されます--バージョン1仕様」、RFC3060、2001年2月。
7.2. Informative References
7.2. 有益な参照
[6] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and S.
Waldbusser, "Terminology for Policy-Based Management", RFC 3198,
November 2001.
[6]Westerinen、A.、Schnizlein、J.、Strassner、J.、Scherling、M.、クイン、B.、ハーツォグ、S.、Huynh、A.、カールソン、M.、ペリー、J.、およびS.Waldbusser、「方針を拠点とする管理のための用語」、RFC3198(2001年11月)。
Barbir, et al. Informational [Page 15] RFC 3838 OPES Policy Requirements August 2004
Barbir、他 [15ページ]情報のRFC3838作品方針要件2004年8月
[7] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[7] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
[8] Christensen, et al., Web Services Description Language (WSDL)
1.1, W3C Note 15 March 2001, http://www.w3.org/TR/wsdl
[8] クリステンセン、他、ウェブサービス記述言語(WSDL)1.1、W3C Note2001年3月15日、 http://www.w3.org/TR/wsdl
8. Acknowledgements
8. 承認
Many thanks to Andreas Terzis, L. Rafalow (IBM), L. Yang (Intel), M. Condry (Intel), Randy Presuhn (Mindspring), and B. Srinivas (Nokia).
アンドレアスTerzis、L.Rafalow(IBM)、L.Yang(インテル)、M.Condry(インテル)、ランディPresuhn(Mindspring)、およびB.Srinivas(ノキア)をありがとうございます。
9. Authors' Addresses
9. 作者のアドレス
Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: +1 613 763 5229 EMail: abbieb@nortelnetworks.com
アビーBarbirノーテルは3500縦梁アベニューネピアン、オンタリオK2H8E9カナダ電話をネットワークでつなぎます: +1 5229年の613 763メール: abbieb@nortelnetworks.com
Oskar Batuner Consultant EMail: batuner@attbi.com
オスカーBatunerコンサルタントメール: batuner@attbi.com
Andre Beck Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733 USA EMail: abeck@bell-labs.com
Crawfordsコーナー道路Holmdel、アンドレべックルーセントテクノロジーズ101ニュージャージー07733米国はメールされます: abeck@bell-labs.com
Tat Chan Nokia 5 Wayside Road Burlington, MA 01803 USA EMail: Tat.Chan@nokia.com
チェンノキア5の道端の道路バーリントン、MA01803米国メールを軽く叩いてください: Tat.Chan@nokia.com
Hilarie Orman Purple Streak Development EMail: ho@alum.mit.edu
Hilarie Ormanは一続きの開発メールを紫色にします: ho@alum.mit.edu
Barbir, et al. Informational [Page 16] RFC 3838 OPES Policy Requirements August 2004
Barbir、他 [16ページ]情報のRFC3838作品方針要件2004年8月
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Barbir, et al. Informational [Page 17]
Barbir、他 情報[17ページ]
一覧
スポンサーリンク
