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
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
Policy, Authorization, and Enforcement Requirements of the Open Pluggable Edge Services (OPES)
开放可插拔边缘服务（OPES）的策略、授权和实施要求
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（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.
本文档描述了选择应用于给定开放可插拔边缘服务（OPES）流的服务的策略、授权和实施要求。
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. 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
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.
开放可插拔边缘服务（OPES）[1]体系结构支持数据提供者、数据使用者和零个或多个OPES处理器之间的协作应用程序服务（OPES服务）。考虑中的应用程序服务分析并可能转换数据提供者和数据使用者之间交换的应用程序级消息。OPES处理器可以通过与一个或多个远程调出服务器通信和协作来分配服务执行的责任。
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.
此类服务的执行由安装在OPES处理器上的一组规则控制。规则评估可触发OPES处理器本地或远程调出服务器上的服务应用程序的执行。
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.
策略将OPES处理器的目标表示为一组用于管理和控制资源访问的规则。本文件中的要求控制OPES实体在确定将哪些可用服务应用于给定消息（如有）时的行为。
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.
本文档中描述的OPES政策范围仅限于描述调用哪些服务以及（如果适用）使用哪些参数的政策。这些策略不包括那些规定被调用服务行为的策略。我们希望启用一个通用的管理框架来为服务的调用和行为指定策略。这种功能的集成是策略管理用户交互应用程序的领域。
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节讨论主体的身份验证和服务的授权。
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.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[4]中所述进行解释。当和规范含义一起使用时，这些关键字将全部大写。这些单词以小写形式出现，包括正常的散文用法，没有任何规范含义。
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].
本节描述体系结构策略分解需求。它还描述了策略组件之间接口的需求。这里的许多规则是在RFC 3238[2]的影响下确定的。
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.
策略功能分解为三个组件：规则作者、策略决策点（PDP）[6]和策略实施点（PEP）[6]。规则作者提供OPES实体使用的规则。这些规则代表规则作者控制服务的调用。PDP和政治公众人物解释收集的规则并适当执行。分解如图1所示。
+--------+ +--------+
| Rule | | Rule |
| Author | ... | Author |
+--------+ +--------+
| |
| |
| +----------+ |
| | Policy | | <- PDP Interface
+--------->| Decision |<----------+
| Point |
+----------+
| ^
| |
| | <- PEP Interface
| |
V |
+--------------+ ...
---> | Policy | --->
| Enforcement | Data Traffic
<--- | Point | <---
+--------------+
+--------+ +--------+
| Rule | | Rule |
| Author | ... | Author |
+--------+ +--------+
| |
| |
| +----------+ |
| | Policy | | <- PDP Interface
+--------->| Decision |<----------+
| Point |
+----------+
| ^
| |
| | <- PEP Interface
| |
V |
+--------------+ ...
---> | Policy | --->
| Enforcement | Data Traffic
<--- | Point | <---
+--------------+
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允许将某些任务卸载到管理服务，该管理服务可能位于与驻留在OPES处理器上的PEP实时强制服务分离的服务器上。
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驻留在数据过滤器中，OPES流中的数据根据编译规则进行评估，并执行对请求服务的适当调用。
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接口）必须使用本文件所述要求可能产生的格式。
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接口）可以是OPES处理器的特定供应商实现的内部接口。仅当PDP和PEP位于不同的OPES处理器上时，实施必须使用标准接口。
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.
策略决策点本质上是一个策略编译器。PDP必须是向实施点提供管理支持的服务。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必须验证指定规则是否在规则作者权限的范围内。PDP必须是OPES管理机构的组成部分。
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.
在OPES体系结构中，数据过滤器表示策略实施点（PEP）。此时，将根据编译后的规则评估来自OPES流的数据，并执行对请求服务的适当调用。
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中，规则可以将动作链接在一起，其中指定了要调用的一系列服务。实现必须确保信息从一个被调用的服务传递到另一个服务。实现不得禁止重新评估消息以确定是否应调用另一个服务或服务集。
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图像的OPES服务会修改请求的web对象的内容类型。
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.
对消息属性值的此类修改可能会改变随后执行的OPES操作的行为。数据筛选器应在评估后续规则之前对匹配的规则进行操作。如果数据过滤器可以提前确定执行任何特定规则不会产生副作用，则可以同时触发多个匹配规则。
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.
数据过滤器可在处理OPES流的过程中多次评估消息。规则处理点可以由管理定义的名称定义。这些名称的定义可以用作策略规则的选择器，以确定规则或规则集在每个处理点的适用性。
Policy roles ([5] and [6]) SHOULD be used where they aid in the development of the OPES policy model.
政策角色（[5]和[6]）应用于帮助制定OPES政策模型的地方。
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显示了数据使用者应用程序、OPES处理器和数据提供者应用程序之间的典型消息数据流。有四个常用的处理点由数字1到4标识。
+--------+ +-----------+ +---------+
| |<------|4 3|<------| |
| Data | | OPES | | Data |
|Consumer| | Processor | |Provider |
| Appl. |------>|1 2|------>| Appl. |
+--------+ +-----------+ +---------+
+--------+ +-----------+ +---------+
| |<------|4 3|<------| |
| Data | | OPES | | Data |
|Consumer| | Processor | |Provider |
| 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）实现必须支持四个规则处理点。
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 数据使用者请求处理角色：这涉及从数据使用者应用程序接收请求时的处理。o OPES处理器请求处理角色：这涉及在转发到数据提供程序应用程序之前的请求处理。o数据提供者响应处理角色：这涉及转发到数据使用者应用程序时的响应处理。o OPES处理器响应处理角色：这涉及转发到数据使用者应用程序时的响应处理。
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.
策略系统和OPES服务之间的接口需要包括传递系统状态信息以及主题消息的能力。
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.
调用的OPES服务必须能够以独立于位置的方式指定。也就是说，规则作者不需要知道，也不需要在规则中指定OPES服务的实例。
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.
规则作者应该能够在细节级别确定适合其需求的所需服务。规则作者应该能够指定服务的类型，或者能够指定适合应用于其流量的一般服务类别的任何服务。
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.
OPES服务名称与特定服务的绑定可在PDP和PEP之间分配。在PDP编译和验证规则时，必须将其解析为特定安装的一组同质OPES服务。
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必须支持将通用名称解析为特定实例。可以使用SLP或UDDI等服务将通用服务名称解析为特定的OPES服务实例。
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接口上指定）本质上是通用的时，规则作者可能不知道特定的服务绑定，例如协议和参数。PDP必须提供所需的绑定信息，并在PEP界面上传达。策略系统中必须存在WSDL[8]等服务描述方法。
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.
可能需要定义和支持一种维护状态信息的方法，该信息可用于条件评估和操作执行。根据执行环境的不同，OPES服务可以自由定义所需的变量，并使用这些变量进一步定义其服务行为，而无需数据过滤器支持。
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.
策略规则可以指定将状态信息用作针对OPES流中给定消息的规则评估的一部分。因此，策略系统应支持维护可用于评估规则条件的组。这些组中的成员资格可以用作操作触发器。
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.
例如，授权网站阻止服务可能会得出结论，不应允许特定用户访问特定网站。与其为此类用户发送的每个请求调用服务，还可以创建一个规则来确定用户是否是被阻止用户的成员，以及请求的站点是否是被阻止站点的成员，然后调用本地阻止服务以向用户返回适当的消息。
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中，应该有一些规定，允许在从服务调用返回时设置变量，并根据策略将变量传递给其他被调用的服务。
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.
本节提供了规则管理的要求。规则分为两组。一些规则由数据使用者应用程序提供，其他规则由数据提供者应用程序提供。
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规则提供程序不能指定不在其权限范围内的规则。o规则提供程序应该只能指定其服务所需的内容。o不同来源的规则汇编不得导致冲突规则的执行。o此类规则冲突的解决超出范围。
o Rules are assumed to be static and applied to current network state.
o 假设规则是静态的，并应用于当前网络状态。
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.
规则需要从规则作者发送到OPES管理服务器，以进行服务授权、规则验证和编译。这样做的机制超出了当前工作的范围。
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.
一旦管理服务器对规则进行授权、验证和编译，就需要将规则发送到OPES处理器。这样做的机制超出了当前工作的范围。
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.
可能需要为所有用户请求或服务器响应调用某些OPES服务，例如，具有日志功能的服务。规则系统应该允许无条件规则，而不是要求规则作者指定始终为真的规则条件。
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.
规则系统必须允许指定在满足规则条件时触发的规则操作。匹配的规则通常会导致调用本地或远程服务。规则操作必须标识要为当前消息请求或响应执行的OPES服务。
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.
规则操作可能包含可用于控制OPES服务行为的运行时参数。如果指定，则必须将这些参数传递给已执行的OPES服务。
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.
OPES处理器必须执行数据消费者和/或数据发布者根据体系结构[1]和本文件设定的政策要求。除非策略中提到的数据元素具有明确的语义和表示形式，否则它们无法始终如一地做到这一点。例如，本文档提到保护用户“身份”和“配置文件”信息。如果用户指定他的身份不能与其他OPES管理信任域共享，并且后来发现他的姓氏已被共享，他可能会投诉。如果他被告知“本网站不认为姓氏是‘身份’”，他可能会觉得自己有理由抱怨。或者，他可能会被告知，当他在OPES服务提供商提供的网络表单上选择“不共享身份”时，这只包括他的登录名，并且必须填写表单的不同部分以保护姓氏。如果此类web表单提供的配置信息被转换为提供给OPES处理器的配置元素，并且软件工程师很难将这些配置元素转换为策略实施，则可能会发生进一步的故障。数据元素可能有令人困惑的名称，或者被分成难以相互关联的组。
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.
这些例子说明了为什么OPES政策必须有数据元素的定义、它们之间的关系以及它们与执行的关系。这些基本项的语义不需要单独的协议，但必须得到所有OPES服务提供商的同意，并且必须确保OPES服务的用户能够知道其设置，如果服务提供商政策允许更改，则可以更改这些设置，并有合理的保证，以合理的解释执行。
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.
OPES规范中对策略数据元素的要求不一定是包罗万象的，但它们必须涵盖支持保护最终用户和发布者数据的策略的最小元素集。
This section considers the authorization and authentication of OPES services.
本节考虑OPES服务的授权和认证。
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.
OPES规则确定哪些流量属性将触发OPES服务的应用。服务的作者可以提供规则，但作者不能提供规则前提的必要部分，以确定哪些网络用户将为他们应用OPES服务。本节讨论如何在规则前提条件中识别用户，以及用户如何为其流量选择和取消选择OPES服务，OPES服务提供商如何识别用户，以及他们如何确定是否将其服务选择添加到OPES实施点。
An OPES service provider MUST satisfy these major requirements:
OPES服务提供商必须满足以下主要要求：
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 允许所有用户请求为其流量添加、删除或阻止OPES服务（阻止意味着“不要将此服务用于我的流量”）。o防止不受信任的用户导致OPES服务干扰其他用户的流量。o允许用户查看其OPES服务配置文件，并通知其更改。o记录所有档案活动，以供审计之用。o遵守保护用户档案的隐私政策。
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中，而无需与网络用户相关的先决条件。这就是规则在交付安装时与OPES服务打包的方式。PDP负责将身份与规则绑定，并将其传输给政治公众人物。PDP用于政策决策的标识必须严格映射到政治公众人物使用的标识。因此，如果用户通过PDP的识别和认证过程，并且通过身份“a”知道，并且如果PEP使用IP地址作为身份，则PDP必须向PEP提供“a”和a的当前IP地址之间的绑定。
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.
代表不同出版网站的OPES服务提供商在实施OPES网站时应牢记上述所有注意事项。由于每个发布站点可能仅由一个标识表示，因此PEP可能更容易处理身份验证和授权数据库。
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和调用服务器、PEP和其他PEP、调用服务器和其他调用服务器之间可能需要进行身份验证。在用户数据或通信量跨越信任域边界的任何情况下，发起信任域应具有描述哪些其他域受信任的策略，并且应在转发信息之前对域及其策略进行身份验证。
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.
当个人选择（或取消选择）OPES服务时，该个人必须经过OPES服务提供商的认证。这意味着以安全的方式在用户的通信信道和服务提供商已知的身份之间进行绑定。这应该使用强身份验证方法完成，并为用户提供公钥证书；这将有助于解决以后的争端。建议服务提供商记录所有OPES服务请求。服务提供商应该使用公钥证书来验证对请求的响应。
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.
服务提供商可能拥有可信任的用户，这些用户可以通过显式或隐式合同为特定用户分配、删除或阻止OPES服务。在允许受信任的用户采取修改策略库的操作之前，必须对其进行身份验证，从而修改政治公众人物的操作。
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之间的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
当OPES服务提供商接受OPES服务时，发布该服务的实体提供的服务必须具有唯一名称。用户可以在请求服务时引用唯一名称。通知用户其服务配置文件时必须使用唯一名称。PEP必须知道可以从其域访问的每个服务的唯一名称。唯一名称和实体之间必须存在加密绑定
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.
负责服务的功能行为，即，如果是人类语言翻译服务，则编写软件的公司名称应绑定到唯一名称。
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 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.
对OPES服务请求的响应可以是肯定的，也可以是否定的。否定响应的原因包括“服务未知”或“PDP策略拒绝服务”。积极响应应该包括请求者和服务的身份以及请求的类型。
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.
如OPES体系结构[1]所述，对OPES服务的请求源自最终用户或发布者域。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的受信任用户仍希望应用该服务。在这种情况下，应以最终用户为准，除非有安全或法律原因将其保留。o发布者和最终用户位于同一域中。如果发布者和最终用户都是PDP的客户端，他们是否可以发出影响彼此处理的请求？在这种情况下，PDP必须具有命名允许设置此类规则的标识的策略规则。o发布者为最终用户请求服务。在这种情况下，如果PDP和PEP位于发布者的管理域中，则发布者可以通过某种方式识别最终用户及其通信量，并且PDP必须使PEP能够实施该策略。这是允许的，但PDP必须使用强有力的方法来识别用户及其流量。用户必须能够请求和接收有关发布者网站保留的关于他的服务配置文件的信息。o最终用户请求特定于发布者身份的服务（例如，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应保持其政策基础，使所有情况下的决策程序易于理解。
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.
请求和响应应以加密方式与请求者和响应者的身份相关联，并且消息不应在未经检测的情况下进行更改。强烈建议将基于证书的数字签名作为身份验证过程的一部分。请求和响应之间的绑定应使用有充分依据的加密手段建立，以表明响应是针对特定请求作出的。
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:
根据政治公众人物的指示，内容将全部或部分由OPES服务进行转换。这意味着无法使用端到端加密保护。这对于绝大多数流量来说可能是可以接受的，但是在需要较少形式的内容保护的情况下，可以使用逐跳保护。此类保护的要求如下：
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 必须在端到端的所有处理点之间使用使用使用共享机密的完整性（即，“跃点”的两端必须共享机密，但“跃点”之间的机密可能不同）。处理点包括详图索引服务器。o可以单独请求加密，在“跃点”之间具有相同的秘密共享要求。请求时，加密将应用于所有处理点，包括详图索引服务器。o完整性信号（以及可选的加密）必须来自请求者（在这种情况下，它也应用于响应）或响应者（在这种情况下，它只覆盖响应）。o对于每个请求者/响应者对，共享秘密必须是唯一的（在非常大的概率确定性范围内）。这有助于保护最终用户数据的隐私，使其在传输提供商网络时免受内部攻击或配置错误。
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必须有关于OPES数据（如服务的用户配置文件）的隐私政策。用户必须能够限制其个人资料数据和身份的发布。
Supported limitations MUST include:
支持的限制必须包括：
o The ability to prevent Identity from being given to callout servers.
o 防止向调出服务器提供标识的功能。
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 防止共享配置文件信息的功能。o能够防止流量数据被发送到由第三方运行的调出服务器。o能够防止来自特定站点的流量被提供给OPES 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).
当OPES服务由第三方提供时，它必须有隐私政策，并向上游和下游方表明自己的身份，告诉他们如何访问其隐私政策。需要一种机制来指定这些首选项，并需要一个协议来分发它们（参见第3.3节）。
This document discusses policy, authorization and enforcement requirements of OPES. In [3] multiple security and privacy issues related to the OPES services are discussed.
本文件讨论了OPE的政策、授权和执行要求。[3]中讨论了与OPES服务相关的多个安全和隐私问题。
[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.，Penno，R.，Chen，R.，Hofmann，M.，和H.Orman，“开放可插拔边缘服务（OPES）的体系结构”，RFC 38352004年8月。
[2] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[2] Floyd，S.和L.Daigle，“开放可插拔边缘服务的IAB架构和政策考虑”，RFC 3238，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.，Hofmann，M.，和H.Orman，“开放可插拔边缘服务（OPES）的安全威胁和风险”，RFC 3837，2004年8月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001.
[5] Moore，B.，Ellesson，E.，Strassner，J.，和A.Westerinen，“策略核心信息模型——版本1规范”，RFC 3060，2001年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] 威斯特林，A.，施尼兹林，J.，斯特拉斯纳，J.，舍林，M.，奎因，B.，赫尔佐格，S.，休恩，A.，卡尔森，M.，佩里，J.，和S.瓦尔德布瑟，“基于政策的管理术语”，RFC 3198，2001年11月。
[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.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，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] Christensen, et al., Web Services Description Language (WSDL)
1.1, W3C Note 15 March 2001, http://www.w3.org/TR/wsdl
Many thanks to Andreas Terzis, L. Rafalow (IBM), L. Yang (Intel), M. Condry (Intel), Randy Presuhn (Mindspring), and B. Srinivas (Nokia).
感谢安德烈亚斯·特齐斯、L.拉法洛（IBM）、L.杨（英特尔）、M.康德里（英特尔）、兰迪·普雷森（Mindspring）和B.斯里尼瓦斯（诺基亚）。
Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: +1 613 763 5229 EMail: abbieb@nortelnetworks.com
Abbie Barbir Nortel Networks加拿大安大略省内皮恩卡林大道3500号K2H 8E9电话：+1 613 763 5229电子邮件：abbieb@nortelnetworks.com
Oskar Batuner Consultant EMail: batuner@attbi.com
Oskar Batuner顾问电子邮件：batuner@attbi.com
Andre Beck Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733 USA EMail: abeck@bell-labs.com
安德烈·贝克·朗讯科技公司，地址：美国新泽西州霍姆德尔市克劳福德角路101号，邮编：07733电子邮件：abeck@bell-实验室网站
Tat Chan Nokia 5 Wayside Road Burlington, MA 01803 USA EMail: Tat.Chan@nokia.com
Tat Chan Nokia 5 Wayside Road Burlington，MA 01803美国电子邮件：Tat。Chan@nokia.com
Hilarie Orman Purple Streak Development EMail: ho@alum.mit.edu
Hilarie Orman紫色条纹开发电子邮件：ho@alum.mit.edu
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.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。