< draft-ietf-opes-authorization-02.txt   draft-ietf-opes-authorization-03.txt >
Network Working Group A. Barbir Network Working Group A. Barbir
Internet-Draft Nortel Networks Internet-Draft Nortel Networks
Expires: August 11, 2003 O. Batuner Expires: October 5, 2004 O. Batuner
Consultant Consultant
A. Beck A. Beck
Lucent Technologies Lucent Technologies
T. Chan T. Chan
Nokia Nokia
H. Orman H. Orman
Purple Streak Development Purple Streak Development
February 10, 2003 April 6, 2004
Policy, Authorization and Enforcement Requirements of OPES Policy, Authorization and Enforcement Requirements of OPES
draft-ietf-opes-authorization-02 draft-ietf-opes-authorization-03
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 11, 2003. This Internet-Draft will expire on October 5, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document describes policy, authorization and enforcement This document describes policy, authorization and enforcement
requirements for the selection of the services to be applied to a requirements for the selection of the services to be applied to a
given OPES flow. given OPES flow.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Policy Architecture . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Policy Components and Functions . . . . . . . . . . . . . . 4 3. Policy Architecture . . . . . . . . . . . . . . . . . . . . . 5
2.2 Requirements For Policy Decision Point . . . . . . . . . . . 6 3.1 Policy Components and Functions . . . . . . . . . . . . . 5
2.3 Requirements for Policy Enforcement Points . . . . . . . . . 6 3.2 Requirements For Policy Decision Point . . . . . . . . . . 6
3. Requirements for Interfaces . . . . . . . . . . . . . . . . 8 3.3 Requirements for Policy Enforcement Points . . . . . . . . 6
3.1 Service Bindings Requirements . . . . . . . . . . . . . . . 8 4. Requirements for Interfaces . . . . . . . . . . . . . . . . . 8
3.1.1 Environment Variables . . . . . . . . . . . . . . . . . . . 8 4.1 Service Bindings Requirements . . . . . . . . . . . . . . 8
3.1.2 Requirements for Using State Information . . . . . . . . . . 9 4.1.1 Environment Variables . . . . . . . . . . . . . . . . 8
3.1.3 Requirements for Passing Information Between Services . . . 9 4.1.2 Requirements for Using State Information . . . . . . . 9
3.2 Requirements for Rule and Rules Management . . . . . . . . . 9 4.1.3 Requirements for Passing Information Between
3.2.1 Requirements for Rule Providers . . . . . . . . . . . . . . 9 Services . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2 Requirements for Rule Formats and Protocols . . . . . . . . 10 4.2 Requirements for Rule and Rules Management . . . . . . . . 9
3.2.3 Requirements for Rule Conditions . . . . . . . . . . . . . . 10 4.2.1 Requirements for Rule Providers . . . . . . . . . . . 9
3.2.4 Requirements for Rule Actions . . . . . . . . . . . . . . . 10 4.2.2 Requirements for Rule Formats and Protocols . . . . . 10
3.3 Requirements for Policy Expression . . . . . . . . . . . . . 11 4.2.3 Requirements for Rule Conditions . . . . . . . . . . . 10
4. Authentication of Principals and Authorization of 4.2.4 Requirements for Rule Actions . . . . . . . . . . . . 10
Services . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3 Requirements for Policy Expression . . . . . . . . . . . . 10
4.1 End users, Publishers and Other Considerations . . . . . . . 12 5. Authentication of Principals and Authorization of Services . . 12
4.1.1 Considerations for end users . . . . . . . . . . . . . . . . 12 5.1 End users, Publishers and Other Considerations . . . . . . 12
4.1.2 Considerations for publishing sites . . . . . . . . . . . . 13 5.1.1 Considerations for end users . . . . . . . . . . . . . 12
4.1.3 Other considerations . . . . . . . . . . . . . . . . . . . . 13 5.1.2 Considerations for publishing sites . . . . . . . . . 13
4.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . 13 5.1.3 Other considerations . . . . . . . . . . . . . . . . . 13
4.3 Authorization . . . . . . . . . . . . . . . . . . . . . . . 14 5.2 Authentication . . . . . . . . . . . . . . . . . . . . . . 13
4.4 Integrity and Encryption . . . . . . . . . . . . . . . . . . 15 5.3 Authorization . . . . . . . . . . . . . . . . . . . . . . 14
4.4.1 Integrity and confidentiality of authentication and 5.4 Integrity and Encryption . . . . . . . . . . . . . . . . . 15
requests/responses for service . . . . . . . . . . . . . . . 15 5.4.1 Integrity and confidentiality of authentication
4.4.2 Integrity and confidentiality of application content . . . . 15 and requests/responses for service . . . . . . . . . . 15
4.5 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.4.2 Integrity and confidentiality of application
Normative References . . . . . . . . . . . . . . . . . . . . 17 content . . . . . . . . . . . . . . . . . . . . . . . 15
Informative References . . . . . . . . . . . . . . . . . . . 18 5.5 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . 21 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 18
7.2 Informative References . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . 21
1. Introduction 1. Introduction
The Open Pluggable Edge Services (OPES) [1] architecture enables The Open Pluggable Edge Services (OPES) [1] architecture enables
cooperative application services (OPES services) between a data cooperative application services (OPES services) between a data
provider, a data consumer, and zero or more OPES processors. The provider, a data consumer, and zero or more OPES processors. The
application services under consideration analyze and possibly application services under consideration analyze and possibly
transform application-level messages exchanged between the data transform application-level messages exchanged between the data
provider and the data consumer. The OPES processor can distribute provider and the data consumer. The OPES processor can distribute
the responsibility of service execution by communicating and the responsibility of service execution by communicating and
collaborating with one or more remote callout servers. collaborating with one or more remote callout servers.
skipping to change at page 4, line 5 skipping to change at page 4, line 5
common management framework for specifying policies for both the common management framework for specifying policies for both the
calling of and the behavior of a service. The integration of such calling of and the behavior of a service. The integration of such
function is the domain of policy administration user interaction function is the domain of policy administration user interaction
applications. applications.
The document is organized as follows:Section 2 considers policy The document is organized as follows:Section 2 considers policy
framework. Section 3 discusses requirements for interfaces, while framework. Section 3 discusses requirements for interfaces, while
section 4 examines authentication of principals and authorization of section 4 examines authentication of principals and authorization of
services. services.
2. Policy Architecture 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 This section describes the architectural policy decomposition
requirements. It also describes the requirements for the interfaces requirements. It also describes the requirements for the interfaces
between the policy components. between the policy components.
2.1 Policy Components and Functions 3.1 Policy Components and Functions
The policy functions are decomposed into three components: a Rule The policy functions are decomposed into three components: a Rule
Author, a Policy Decision Point (PDP) and Policy Enforcement Point Author, a Policy Decision Point (PDP) and Policy Enforcement Point
(PEP). The Rule Author provides the rules to be used by an OPES (PEP). The Rule Author provides the rules to be used by an OPES
entity. These rules control the invocation of services on behalf of entity. These rules control the invocation of services on behalf of
the rule author. The PDP and the PEP interpret the collected rules the rule author. The PDP and the PEP interpret the collected rules
and appropriately enforce them. The decomposition is illustrated in and appropriately enforce them. The decomposition is illustrated in
Figure 1. Figure 1.
+--------+ +--------+ +--------+ +--------+
skipping to change at page 5, line 43 skipping to change at page 6, line 15
The PDP provides for the authentication and authorization of rule The PDP provides for the authentication and authorization of rule
authors and the validation and compilation of rules. authors and the validation and compilation of rules.
The PEP resides in the data filter where the data from an OPES flow 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 is evaluated against the compiled rules and appropriate calls to the
requested services are performed. requested services are performed.
Interfaces between these architectural components are points of Interfaces between these architectural components are points of
interoperability. The interface between rule authors and the policy interoperability. The interface between rule authors and the policy
decision points (PDP Interface) must use the standard format that may decision points (PDP Interface) MUST use the standard format that may
result from the requirements as described in this document. result from the requirements as described in this document.
The interface between the policy decision points and the policy The interface between the policy decision points and the policy
enforcement points (PEP Interface) can be internal to a specific enforcement points (PEP Interface) can be internal to a specific
vendor implementation of an OPES processor. Implementations must use vendor implementation of an OPES processor. Implementations MUST use
standard interface only if the PDP and the PEP reside on different standard interface only if the PDP and the PEP reside on different
OPES processor. OPES processor.
2.2 Requirements For Policy Decision Point 3.2 Requirements For Policy Decision Point
The Policy Decision Point is essentially a policy compiler. The PDP The Policy Decision Point is essentially a policy compiler. The PDP
must be a service that provides administrative support to the MUST be a service that provides administrative support to the
enforcement points. The PDP service must authenticate the rule enforcement points. The PDP service MUST authenticate the rule
authors. authors.
The PDP must verify that the specified rules are within the scope of 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 the rule authors authority. The PDP MUST be a component of the OPES
Administration Authority. Administration Authority.
2.3 Requirements for Policy Enforcement Points 3.3 Requirements for Policy Enforcement Points
In the OPES architecture, the data filter represents a Policy In the OPES architecture, the data filter represents a Policy
Enforcement point (PEP). At this point, data from an OPES flow is Enforcement point (PEP). At this point, data from an OPES flow is
evaluated against the compiled rules and appropriate calls to the evaluated against the compiled rules and appropriate calls to the
requested services are performed. requested services are performed.
In the PEP rules may chain actions together, where, a series of In the PEP rules MAY chain actions together, where, a series of
services to be called are specified. Implementation must ensure the services to be called are specified. Implementation MUST ensure the
passing of information from one called service to another. passing of information from one called service to another.
Implementation must not prohibit the re-evaluation of a message to Implementation MUST NOT prohibit the re-evaluation of a message to
determine if another service or set of services should be called. 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 The execution of an action (i.e., the triggering of a rule) may lead
to the modification of a message property values. For example, an to the modification of a message property values. For example, an
OPES service that under some circumstances converts JPEG images to OPES service that under some circumstances converts JPEG images to
GIF images modifies the content type of the requested web object. GIF images modifies the content type of the requested web object.
Such modification of message property values may change the behavior Such modification of message property values may change the behavior
of subsequently performed OPES actions. The data filter should act on of subsequently performed OPES actions. The data filter SHOULD act on
matched rules before it evaluates subsequent rules. Multiple matched matched rules before it evaluates subsequent rules. Multiple matched
rules can be triggered simultaneously if the data filter can rules can be triggered simultaneously if the data filter can
determine in advance that there are no side effects from the determine in advance that there are no side effects from the
execution of any specific rule. execution of any specific rule.
A data filter may evaluate messages several times in the course of A data filter MAY evaluate messages several times in the course of
handling an OPES flow. The rule processing points may be defined by handling an OPES flow. The rule processing points MAY be defined by
administratively defined names. The definition of such names can administratively defined names. The definition of such names can
serve as a selector for policy rules to determine the applicability serve as a selector for policy rules to determine the applicability
of a rule or a set of rules at each processing point. The scope of of a rule or a set of rules at each processing point. The scope of
policy control of policy roles as defined RFC 3060 should be used policy control of policy roles as defined RFC 3060 SHOULD be used
where it aids in the development of the OPES policy model. where it aids in the development of the OPES policy model.
In Figure 2 a typical message data flow between a data consumer In Figure 2 a typical message data flow between a data consumer
application, an OPES processor and a data provider application. There application, an OPES processor and a data provider application. There
are four commonly used processing points identified by the numbers 1 are four commonly used processing points identified by the numbers 1
through 4. through 4.
+--------+ +-----------+ +---------+ +--------+ +-----------+ +---------+
| |<------|4 3|<------| | | |<------|4 3|<------| |
| Data | | OPES | | Data | | Data | | OPES | | Data |
|Consumer| | Processor | |Provider | |Consumer| | Processor | |Provider |
| Appl. |------>|1 2|------>| Appl. | | Appl. |------>|1 2|------>| Appl. |
+--------+ +-----------+ +---------+ +--------+ +-----------+ +---------+
Figure 2: Processing Execution Points Figure 2: Processing Execution Points
Any data filter (PEP) or any administrative (PDP) implementation must Any data filter (PEP) or any administrative (PDP) implementation MUST
support the four rule processing points. support the four rule processing points.
o Data Consumer Request Handling Role : This involves request o Data Consumer Request Handling Role : This involves request
processing when received from a Data Consumer Application. processing when received from a Data Consumer Application.
o OPES Processor Request handling role: This involves request o OPES Processor Request handling role: This involves request
processing before forwarding to Data Provider Application. processing before forwarding to Data Provider Application.
o Data Provider Response handling role: This involves response o Data Provider Response handling role: This involves response
processing when forwarding to Data Consumer Application. processing when forwarding to Data Consumer Application.
o OPES Processor Response handling role:This involves response o OPES Processor Response handling role:This involves response
processing when forwarding to Data Consumer Application. processing when forwarding to Data Consumer Application.
3. Requirements for Interfaces 4. Requirements for Interfaces
The interface between the policy system and OPES services needs to The interface between the policy system and OPES services needs to
include the ability to pass system state information as well as the include the ability to pass system state information as well as the
subject message. subject message.
3.1 Service Bindings Requirements 4.1 Service Bindings Requirements
The invoked OPES services must be able to be specified in a location 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 independent fashion. That is, the rule authors need not know and need
not specify the instance of an OPES service in the rules. not specify the instance of an OPES service in the rules.
The rule author should be able to identify the required service at 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 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 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 specify any service that fits a general category of service to be
applied its traffic. applied its traffic.
The binding of OPES service names to specific service may be The binding of OPES service names to specific service MAY be
distributed between the PDP and the PEP. As rules are compiled and distributed between the PDP and the PEP. As rules are compiled and
validated by the PDP, they must be resolved to a specific validated by the PDP, they MUST be resolved to a specific
installations' set of homogeneous OPES service. installations' set of homogeneous OPES service.
The selection of a specific instance may be postponed and left to PEP The selection of a specific instance MAY be postponed and left to PEP
to select at either rule installation time or at run time. To achieve to select at either rule installation time or at run time. To achieve
interoperability, PEP must support resolving a generic name to a interoperability, PEP MUST support resolving a generic name to a
specific instance. It is possible to use services such as SLP or UDDI specific instance. It is possible to use services such as SLP or UDDI
to resolve generic service names to specific OPES service instances. to resolve generic service names to specific OPES service instances.
The policy system may support dynamic discovery of service bindings. The policy system MAY support dynamic discovery of service bindings.
The rule author may, not know specific service bindings such as The rule author may not know specific service bindings such as
protocol and parameters, when a rule (as specified on the PDP protocol and parameters, when a rule (as specified on the PDP
Interface) is general in nature. The required binding information Interface) is general in nature. The required binding information
must be provided by the PDP and conveyed on the PEP Interface. A MUST be provided by the PDP and conveyed on the PEP Interface. A
service description methodology such as WSDL must be present in the service description methodology such as WSDL MUST be present in the
policy system. It is to be determined whether an OPES standard is policy system. It is to be determined whether an OPES standard is
required. required.
3.1.1 Environment Variables 4.1.1 Environment Variables
There may be a need to define and support means for maintaining state There may be a need to define and support means for maintaining state
information that can be used in both condition evaluation and action information that can be used in both condition evaluation and action
execution. Depending on the execution environment, OPES services may execution. Depending on the execution environment, OPES services MAY
have the freedom to define variables that are needed and use these have the freedom to define variables that are needed and use these
variables to further define their service behavior without the data variables to further define their service behavior without the data
filter support. filter support.
3.1.2 Requirements for Using State Information 4.1.2 Requirements for Using State Information
Policy rules may specify that state information be used as part of 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. the evaluation of the rules against a given message in an OPES flow.
Thus, the policy system should support the maintenance of groups that 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 in evaluating rule conditions. Membership in such groups
can be used as action triggers. can be used as action triggers.
For example, an authorized site blocking service might conclude that For example, an authorized site blocking service might conclude that
a particular user shouldn't be permitted access to a certain web 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 site. Rather than calling the service for each request sent by such a
user, a rule might be created that determine if user is a member of user, a rule might be created that determine if user is a member of
blocked users and requested site is a member of blocked-sites then blocked users and requested site is a member of blocked-sites then
invoke a local blocking service to return and return an appropriate invoke a local blocking service to return and return an appropriate
message to the user. message to the user.
3.1.3 Requirements for Passing Information Between Services 4.1.3 Requirements for Passing Information Between Services
Environment variables can be used to pass state information between Environment variables can be used to pass state information between
services. For example, analysis of the request or modifications to services. For example, analysis of the request or modifications to
the request may need to be captured as state information that can be 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 passed to other services on the request path or to services on the
response(s) associated with that request. response(s) associated with that request.
In the PEP, there should be provisions to enable setting up variables In the PEP, there SHOULD be provisions to enable setting up variables
when returning from a service call and passing variables to other when returning from a service call and passing variables to other
called services based on policy. called services based on policy.
3.2 Requirements for Rule and Rules Management 4.2 Requirements for Rule and Rules Management
This section provides the requirements for rule management. The rules This section provides the requirements for rule management. The rules
are divided into two groups. Some rules are provided by the data are divided into two groups. Some rules are provided by the data
consumer application and other rules are provided by the data consumer application and other rules are provided by the data
provider application. provider application.
3.2.1 Requirements for Rule Providers 4.2.1 Requirements for Rule Providers
The requirements for rule providers are: The requirements for rule providers are:
o Rule providers MUST be authenticated and authorized for rules that
o Rule providers must be authenticated and authorized for rules that
apply to their network role. apply to their network role.
o Rule providers MUST NOT be able to specify rules that are NOT
o Rule providers must not be able to specify rules that are not
within their scope of authority. within their scope of authority.
o Rule providers SHOULD be able to specify only what is needed for
o Rule providers should be able to specify only what is needed for
their services. their services.
o Compilation of rules from different sources MUST NOT lead to
o Compilation of rules from different sources must not lead to
execution of conflicting rules. execution of conflicting rules.
o The resolution of such rule conflicts is out of scope o The resolution of such rule conflicts is out of scope
o Rules are assumed to be static and applied to current network o Rules are assumed to be static and applied to current network
state. state.
3.2.2 Requirements for Rule Formats and Protocols 4.2.2 Requirements for Rule Formats and Protocols
It is desirable to choose standard technologies like XML to specify It is desirable to choose standard technologies like XML to specify
the rule language format. the rule language format.
Rules need to be sent form the rule authors to the OPES Rules need to be sent form the rule authors to the OPES
administrative server for service authorization, rule validation and administrative server for service authorization, rule validation and
compilation. The mechanisms for doing that are out of scope of the compilation. The mechanisms for doing that are out of scope of the
current work. current work.
Once the rules are authorized, validated and compiled by the Once the rules are authorized, validated and compiled by the
administrative server, the rules need to be sent to the OPES administrative server, the rules need to be sent to the OPES
processor. The mechanisms for doing that are out of scope of the processor. The mechanisms for doing that are out of scope of the
current work. current work.
3.2.3 Requirements for Rule Conditions 4.2.3 Requirements for Rule Conditions
Rule conditions must be matched against attribute values of the Rule conditions MUST be matched against attribute values of the
encapsulated protocol as well as environment variable values. encapsulated protocol as well as environment variable values.
Attribute values of the encapsulated protocol include protocol header Attribute values of the encapsulated protocol include protocol header
values and possibly also protocol body values. values and possibly also protocol body values.
Some OPES services may need to be invoked for all users requests or Some OPES services may need to be invoked for all users requests or
server responses, services with logging functionality, as an example. server responses, services with logging functionality, as an example.
The rule system should allow unconditional rules rather than The rule system SHOULD allow unconditional rules rather than
requiring rule authors to specify rule conditions that are always requiring rule authors to specify rule conditions that are always
true. true.
3.2.4 Requirements for Rule Actions 4.2.4 Requirements for Rule Actions
The rule system must allow for the specification of rule actions that The rule system MUST allow for the specification of rule actions that
are triggered if the conditions of a rule are met. Matched rules are triggered if the conditions of a rule are met. Matched rules
typically lead to the invocation of local or remote services. Rule typically lead to the invocation of local or remote services. Rule
actions must identify the OPES service that is to be executed for the actions MUST identify the OPES service that is to be executed for the
current message request or response. current message request or response.
Rule actions may contain run-time parameters which can be used to Rule actions MAY contain run-time parameters which can be used to
control the behavior of an OPES service. If specified, these control the behavior of an OPES service. If specified, these
parameters must be passed to the executed OPES service. parameters MUST be passed to the executed OPES service.
3.3 Requirements for Policy Expression 4.3 Requirements for Policy Expression
OPES processors must enforce policy requirements set by data OPES processors MUST enforce policy requirements set by data
consumers and/or data publishers in accordance with the architecture consumers and/or data publishers in accordance with the architecture
[ref ARCH] and this document. They cannot do this consistently
unless there is an unambiguous semantics and representation of the [1] and this document. They cannot do this consistently unless there
data elements mentioned in the policy. For example, this document is an unambiguous semantics and representation of the data elements
mentions protection of user "identity" and "profile" information. If mentioned in the policy. For example, this document mentions
a user specifies that his identity must not be shared with other OPES 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 administrative trust domains and later discovers that his family name
has been shared, he might complain. If he were told that "family has been shared, he might complain. If he were told that "family
names are not considered 'identities' by this site", he would names are not considered 'identities' by this site", he would
probably feel that he had cause for complaint. Or, he might be told 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 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, 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 and that a different part of the form had to be filled out to protect
family name. A further breakdown can occur if the configuration family name. A further breakdown can occur if the configuration
information provided by such a web form gets translated into information provided by such a web form gets translated into
configuration elements given to an OPES processor, and those configuration elements given to an OPES processor, and those
configuration elements are difficult for a software engineer to configuration elements are difficult for a software engineer to
translate into policy enforcement. The data elements might have translate into policy enforcement. The data elements might have
confusing names or be split into groupings that are difficult to confusing names or be split into groupings that are difficult to
relate to one another. relate to one another.
The examples illustrate why OPES policy must have definitions of data The examples illustrate why OPES policy MUST have definitions of data
elements, their relationships, and how they relate to enforcement. elements, their relationships, and how they relate to enforcement.
These semantics of essential items do not require a separate These semantics of essential items do not require a separate
protocol, but they must be agreed upon by all OPES service providers, 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 and the users of OPES services MUST be assured that they have the
ability to know their settings, to change them if the service ability to know their settings, to change them if the service
provider policy allows the changes, and to have reasonable assurance provider policy allows the changes, and to have reasonable assurance
that they are enforced with reasonable interpretations. that they are enforced with reasonable interpretations.
The requirements for policy data elements in the OPES specification The requirements for policy data elements in the OPES specification
do not have to be all-inclusive, but they must cover the minimal set 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 of elements that enable the policies that protect the data of end
users and publishers. users and publishers.
4. Authentication of Principals and Authorization of Services 5. Authentication of Principals and Authorization of Services
This section considers the authorization and authentication of OPES This section considers the authorization and authentication of OPES
services. services.
4.1 End users, Publishers and Other Considerations 5.1 End users, Publishers and Other Considerations
4.1.1 Considerations for end users 5.1.1 Considerations for end users
An OPES rule determines which attributes of traffic will trigger the An OPES rule determines which attributes of traffic will trigger the
application of an OPES services. The author of the service can application of an OPES services. The author of the service can
supply rules, but the author cannot supply the necessary part of the supply rules, but the author cannot supply the necessary part of the
rule precondition that determines which network users will have the rule precondition that determines which network users will have the
OPES services applied for them. This section discusses how users are OPES services applied for them. This section discusses how users are
identified in the rule preconditions, and how users can select and identified in the rule preconditions, and how users can select and
deselect OPES services for their traffic, how an OPES service deselect OPES services for their traffic, how an OPES service
provider should identify the users, and how they determine whether or provider SHOULD identify the users, and how they determine whether or
not to add their service selection to an OPES enforcement point. not to add their service selection to an OPES enforcement point.
An OPES service provider must satisfy these major requirements: An OPES service provider MUST satisfy these major requirements:
o Allow all users to request addition, deletion, or blocking of OPES o Allow all users to request addition, deletion, or blocking of OPES
services for their traffic (blocking means "do not use this services for their traffic (blocking means "do not use this
service for my traffic"). service for my traffic").
o Prevent untrusted users from causing OPES services to interfere o Prevent untrusted users from causing OPES services to interfere
with the traffic of other users. with the traffic of other users.
o Allow users to see their OPES service profiles and notify them of o Allow users to see their OPES service profiles and notify them of
changes. changes.
o Keep a log of all profile activity for audit purposes. o Keep a log of all profile activity for audit purposes.
o Adhere to a privacy policy guarding users' profiles. o Adhere to a privacy policy guarding users' profiles.
The administrator of the PDP is a trusted party and can set policy The administrator of the PDP is a trusted party and can set policy
for individuals or groups using out-of-band communication and for individuals or groups using out-of-band communication and
configuration files. However, users must always be able to query the configuration files. However, users MUST always be able to query the
PDP in order to learn what rules apply to their traffic. PDP in order to learn what rules apply to their traffic.
Rules can be deposited in the PDP with no precondition relating to Rules can be deposited in the PDP with no precondition relating to
network users. This is the way rules are packaged with an OPES network users. This is the way rules are packaged with an OPES
service when it is delivered for installation. The PDP is service when it is delivered for installation. The PDP is
responsible for binding identities to the rules and transmitting them responsible for binding identities to the rules and transmitting them
to the PEP. The identity used by the PDP for policy decisions must be 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 strictly mapped to the identity used by the PEP. Thus, if a user
goes through and identification and authentication procedure with the goes through and identification and authentication procedure with the
PDP and is known by identity "A", and if the PEP uses IP addresses 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 for identities, then the PDP MUST provide the PEP with a binding
between "A" and A's current IP address. between "A" and A's current IP address.
4.1.2 Considerations for publishing sites 5.1.2 Considerations for publishing sites
An OPES service provider acting on behalf of different publishing An OPES service provider acting on behalf of different publishing
sites should keep all the above considerations in mind when sites SHOULD keep all the above considerations in mind when
implementing an OPES site. Because each publishing site may be implementing an OPES site. Because each publishing site may be
represented by only a single identity, the authentication and represented by only a single identity, the authentication and
authorization databases may be easier for the PEP to handle. authorization databases may be easier for the PEP to handle.
4.1.3 Other considerations 5.1.3 Other considerations
Authentication may be necessary between PDP's and PEP's, PEP's and Authentication may be necessary between PDP's and PEP's, PEP's and
callout servers, PEP's and other PEP's, callout servers and other callout servers, PEP's and other PEP's, callout servers and other
callout servers, for purposes of validating privacy policies. In any callout servers, for purposes of validating privacy policies. In any
case where user data or traffic crosses trust domain boundaries, the case where user data or traffic crosses trust domain boundaries, the
originating trust domain should have a policy describing which other originating trust domain SHOULD have a policy describing which other
domains are trusted, and it should authenticate the domains and their domains are trusted, and it SHOULD authenticate the domains and their
policies before forwarding information. policies before forwarding information.
4.2 Authentication 5.2 Authentication
When an individual selects (or deselects) an OPES service, the When an individual selects (or deselects) an OPES service, the
individual must be authenticated by the OPES service provider. This individual MUST be authenticated by the OPES service provider. This
means that a binding between the user's communication channel and an means that a binding between the user's communication channel and an
identity known to the service provider is made in a secure manner. identity known to the service provider is made in a secure manner.
This SHOULD be done using a strong authentication method with a This SHOULD be done using a strong authentication method with a
public key certificate for the user; this will be helpful in public key certificate for the user; this will be helpful in
resolving later disputes. It is recommended that the service resolving later disputes. It is recommended that the service
provider keep a log of all requests for OPES services. The service provider keep a log of all requests for OPES services. The service
provider SHOULD use public key certficates to authenticate responses provider SHOULD use public key certficates to authenticate responses
to requests. to requests.
The service provider may have trusted users who through explicit or The service provider may have trusted users who through explicit or
implicit contract can assign, remove, or block OPES services for implicit contract can assign, remove, or block OPES services for
particular users. The trusted users MUST be authenticated before particular users. The trusted users MUST be authenticated before
being allowed to take actions which will modify the policy base, and being allowed to take actions which will modify the policy base, and
thus, the actions of the PEP's. thus, the actions of the PEP's.
Because of the sensitivity of user profiles, the PEP Interface Because of the sensitivity of user profiles, the PEP Interface
between the PEP and the PDP MUST use a secure transport protocol. The 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's MUST adhere to the privacy preferences of the users.
When an OPES service provider accepts an OPES service, there must be When an OPES service provider accepts an OPES service, there MUST be
a unique name for the service provided by the entity publishing the a unique name for the service provided by the entity publishing the
service. Users may refer to the unique name when requesting a service. Users MAY refer to the unique name when requesting a
service. The unique name must be when notifying users about their service. The unique name MUST be used when notifying users about
service profiles. PEP's must be aware of the unique name for each their service profiles. PEP's MUST be aware of the unique name for
service that can be accessed from their domain. There MUST be a each service that can be accessed from their domain. There MUST be a
cryptographic binding between the unique name and the entity cryptographic binding between the unique name and the entity
responsible for the functional behavior of the service; i.e., if it responsible for the functional behavior of the service; i.e., if it
is a human language translating service then the name of company that is a human language translating service then the name of company that
wrote the software should be bound to the unique name. wrote the software SHOULD be bound to the unique name.
4.3 Authorization 5.3 Authorization
In addition to requesting or terminating specific services, users may In addition to requesting or terminating specific services, users MAY
block particular services, indicating that the services should not be block particular services, indicating that the services should not be
applied to their traffic. The "block all OPES" directive must be applied to their traffic. The "block all OPES" directive MUST be
supported on a per user basis. supported on a per user basis.
A response to a request for an OPES service can be positive or A response to a request for an OPES service can be positive or
negative. Reasons for a negative response include "service unknown" negative. Reasons for a negative response include "service unknown"
or "service denied by PDP policy". Positive responses should include or "service denied by PDP policy". Positive responses SHOULD include
the identity of the requestor and the service and the type of the identity of the requestor and the service and the type of
request. request.
As described in the OPES Architecture [1], requests for OPES services As described in the OPES Architecture [1], requests for OPES services
originate in either the enduser or the publisher domain. The PDP originate in either the enduser or the publisher domain. The PDP
bases its authorization decision on the requestor and the domain. bases its authorization decision on the requestor and the domain.
There are some cases where the decision may be complicated. There are some cases where the decision may be complicated.
o The end user has blocked a service, but a trusted user of the 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 wants it applied anyway. In this case, the end user SHOULD
prevail, unless their are security or legal reasons to leave it in prevail, unless their are security or legal reasons to leave it in
place. place.
o The publisher and the enduser are in the same domain. If the o The publisher and the enduser are in the same domain. If the
publisher and enduser are both clients of a PDP, can they make publisher and enduser are both clients of a PDP, can they make
requests that effect each other's processing? In this case, the requests that effect each other's processing? In this case, the
PDP must have policy rules naming the identities that are allowed PDP MUST have policy rules naming the identities that are allowed
to set such rules. to set such rules.
o The publisher requests a service for an enduser. In this case, in o The publisher requests a service for an enduser. In this case, in
which the PDP and PEP are in the publisher's administrative which the PDP and PEP are in the publisher's administrative
domain, the publisher has some way of identifying the end user and domain, the publisher has some way of identifying the end user and
his traffic, and the PDP must enable the PEP to enforce the his traffic, and the PDP MUST enable the PEP to enforce the
policy. This is allowed, but the PDP MUST use strong methods to policy. This is allowed, but the PDP MUST use strong methods to
identify the user and his traffic. The user must be able to identify the user and his traffic. The user MUST be able to
request and receive information about the service profile that a request and receive information about the service profile that a
publisher site keeps about him. publisher site keeps about him.
o The enduser requests a service specific to a publisher identity o The enduser requests a service specific to a publisher identity
(e.g., nfl.com), but the publisher prohibits the service (e.g., (e.g., nfl.com), but the publisher prohibits the service (e.g.,
through a "NO OPES" application header). As in the case above, through a "NO OPES" application header). As in the case above,
the publisher must be able to request and receive profile the publisher MUST be able to request and receive profile
information that a user keeps about a publisher. information that a user keeps about a publisher.
In general, the PDP should keep its policy base in a manner that In general, the PDP SHOULD keep its policy base in a manner that
makes the decision procedure for all cases easy to understand. makes the decision procedure for all cases easy to understand.
4.4 Integrity and Encryption 5.4 Integrity and Encryption
4.4.1 Integrity and confidentiality of authentication and requests/ 5.4.1 Integrity and confidentiality of authentication and requests/
responses for service responses for service
The requests and responses should be cryptographically tied to the The requests and responses SHOULD be cryptographically tied to the
identities of the requestor and responder, and the messages should identities of the requestor and responder, and the messages SHOULD
not alterable without detection. A certificate-based digital not be alterable without detection. A certificate-based digital
signature is strongly recommended as part of the authentication signature is strongly recommended as part of the authentication
process. A binding between the request and response should be process. A binding between the request and response SHOULD be
established using well-founded cryptographic means, to show that the established using well-founded cryptographic means, to show that the
response is made in reply to a specific request. response is made in reply to a specific request.
4.4.2 Integrity and confidentiality of application content 5.4.2 Integrity and confidentiality of application content
As directed by the PEP, content will be transformed in whole or in As directed by the PEP, content will be transformed in whole or in
part by OPES services. This means that end-to-end cryptographic part by OPES services. This means that end-to-end cryptographic
protections cannot be used. This is probably acceptable for the vast protections cannot be used. This is probably acceptable for the vast
majority of traffic, but in cases where a lesser form of content majority of traffic, but in cases where a lesser form of content
protection is desirable, hop-by-hop protections can be used instead. protection is desirable, hop-by-hop protections can be used instead.
The requirements for such protections are: The requirements for such protections are:
o Integrity using shared secrets MUST be used between all processing o Integrity using shared secrets MUST be used between all processing
points, end-to-end (i.e., the two ends a "hop" must share a points, end-to-end (i.e., the two ends a "hop" MUST share a
secret, but the secret can be different between "hops"). The secret, but the secret can be different between "hops"). The
processing points include the callout servers. processing points include the callout servers.
o Encryption can be requested separately, with the same secret o Encryption can be requested separately, with the same secret
sharing requirement between "hops". When requested, encryption sharing requirement between "hops". When requested, encryption
applies to all processing points, including callout servers. applies to all processing points, including callout servers.
o The signal for integrity (and optionally encryption) MUST
o The signal for integrity (and optionally encryption) must
originate from either the requestor (in which case it is applied originate from either the requestor (in which case it is applied
to the response as well) or the responder (in which case it covers to the response as well) or the responder (in which case it covers
only the response). only the response).
o The shared secrets MUST be unique (to within a very large
o The shared secrets must be unique (to within a very large
probabilistic certainty) for each requestor/responder pair. This probabilistic certainty) for each requestor/responder pair. This
helps to protect the privacy of enduser data from insider attacks helps to protect the privacy of enduser data from insider attacks
or configuration errors while it transits the provider's network. or configuration errors while it transits the provider's network.
4.5 Privacy 5.5 Privacy
The PDP must have a privacy policy regarding OPES data such as user The PDP MUST have a privacy policy regarding OPES data such as user
profiles for services. Users MUST be able to limit the promulgation profiles for services. Users MUST be able to limit the promulgation
of their profile data and their identities. of their profile data and their identities.
Supported limitations MUST include: Supported limitations MUST include:
o The ability to prevent Identity from being given to callout
o Identity MAY not be given to callout servers.
o Profile information MAY not be shared.
o Traffic data MAY not be sent to callout servers run by third
parties.
o Traffic from particular sites SHOULD not be given to OPES callout
servers. servers.
When an OPES service is provided by a third-party, it must have a 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.
When an OPES service is provided by a third-party, it MUST have a
privacy policy and identify itself to upstream and downstream privacy policy and identify itself to upstream and downstream
parties, telling them how to access its privacy policy. A mechanism parties, telling them how to access its privacy policy. A mechanism
is needed to specify these preferences and a protocol to distribute is needed to specify these preferences and a protocol to distribute
that (see section 3.3). that (see section 3.3).
Normative References 6. Security Considerations
This document discusses policy, authorization and enforcement
requirements of OPES. In [3] multiple security and privacy issues
related to the OPES services are discussed.
7. References
7.1 Normative References
[1] A. Barbir et. al, "An Architecture for Open Pluggable Edge [1] A. Barbir et. al, "An Architecture for Open Pluggable Edge
Services (OPES)", Internet-Draft: http://www.ietf.org/ Services (OPES)", Internet-Draft: http://www.ietf.org/
internet-drafts/draft-ietf-opes-architecture-04.txt, December internet-drafts/draft-ietf-opes-architecture-04.txt, December
2002. 2002.
[2] Floyd, S. and L. Daigle, "IAB Architectural and Policy [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC 3238, Considerations for Open Pluggable Edge Services", RFC 3238,
January 2002. January 2002.
Informative References [3] Barbir et. al, A., "Security Threats and Risks for OPES",
Internet-Draft: http://www.ietf.org/internet-drafts/
draft-ietf-opes-threats-03.txt, December 2003.
[3] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
7.2 Informative References
[5] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S.
Waldbusser, "Terminology for Policy-Based Management", RFC 3198, Waldbusser, "Terminology for Policy-Based Management", RFC 3198,
November 2001. November 2001.
[4] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., [6] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999. HTTP/1.1", RFC 2616, June 1999.
Authors' Addresses Authors' Addresses
Abbie Barbir Abbie Barbir
Nortel Networks Nortel Networks
3500 Carling Avenue 3500 Carling Avenue
Nepean, Ontario K2H 8E9 Nepean, Ontario K2H 8E9
Canada Canada
skipping to change at page 19, line 4 skipping to change at page 19, line 24
EMail: abeck@bell-labs.com EMail: abeck@bell-labs.com
Tat Chan Tat Chan
Nokia Nokia
5 Wayside Road 5 Wayside Road
Burlington, MA 01803 Burlington, MA 01803
USA USA
EMail: Tat.Chan@nokia.com EMail: Tat.Chan@nokia.com
Hilarie Orman Hilarie Orman
Purple Streak Development Purple Streak Development
Phone: Phone:
EMail: ho@alum.mit.edu EMail: ho@alum.mit.edu
Appendix A. Acknowledgements Appendix A. Acknowledgements
Many thanks to Andreas Terzis, L. Rafalow (IBM), L. Yang (Intel), M. Many thanks to Andreas Terzis, L. Rafalow (IBM), L. Yang (Intel), M.
Condry (Intel) and B. Srinivas (Nokia) Condry (Intel), Randy Presuhn (Mindspring) and B. Srinivas (Nokia)
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
skipping to change at page 21, line 29 skipping to change at page 21, line 29
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
skipping to change at page 22, line 7 skipping to change at page 22, line 7
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 123 change blocks. 
186 lines changed or deleted 194 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/