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)
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).
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.
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
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.
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.
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.
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. Terminology
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.
3. Policy Architecture
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].
3.1. Policy Components and Functions
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.
+--------+ +--------+
| Rule | | Rule |
| Author | ... | Author |
+--------+ +--------+
| |
| |
| +----------+ |
| | Policy | | <- PDP Interface
+--------->| Decision |<----------+
| Point |
+----------+
| ^
| |
| | <- PEP Interface
| |
V |
+--------------+ ...
---> | Policy | --->
| Enforcement | Data Traffic
<--- | Point | <---
+--------------+
Figure 1: Policy Components
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.
The PDP provides for the authentication and authorization of rule
authors and the validation and compilation of rules.
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.
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.
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.
3.2. Requirements for Policy Decision Points
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.
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.
3.3. Requirements for Policy Enforcement Points
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.
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.
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.
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.
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.
Policy roles ([5] and [6]) SHOULD be used where they aid in the
development of the OPES policy model.
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.
+--------+ +-----------+ +---------+
| |<------|4 3|<------| |
| Data | | OPES | | Data |
|Consumer| | Processor | |Provider |
| Appl. |------>|1 2|------>| Appl. |
+--------+ +-----------+ +---------+
Figure 2: Processing Execution Points
Any data filter (PEP) or any administrative (PDP) implementation MUST
support the four rule processing points.
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.
4. Requirements for Interfaces
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.
4.1. Service Bindings Requirements
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.
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.
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.
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.
4.1.1. Environment Variables
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.
4.1.2. Requirements for Using State Information
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.
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
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.
4.2. Requirements for Rule and Rules Management
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.
4.2.1. Requirements for Rule Providers
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 Rules are assumed to be static and applied to current network
state.
4.2.2. Requirements for Rule Formats and Protocols
It is desirable to choose standard technologies like XML to specify
the rule language format.
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
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.
4.2.4. Requirements for Rule Actions
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.
4.3. Requirements for Policy Expression
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.
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