summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3838.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3838.txt')
-rw-r--r--doc/rfc/rfc3838.txt955
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc3838.txt b/doc/rfc/rfc3838.txt
new file mode 100644
index 0000000..0ed29a1
--- /dev/null
+++ b/doc/rfc/rfc3838.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+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)
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbir, et al. Informational [Page 1]
+
+RFC 3838 OPES Policy Requirements August 2004
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+Barbir, et al. Informational [Page 2]
+
+RFC 3838 OPES Policy Requirements August 2004
+
+
+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.
+
+
+
+
+
+
+
+Barbir, et al. Informational [Page 3]
+
+RFC 3838 OPES Policy Requirements August 2004
+
+
+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.
+
+
+
+
+
+Barbir, et al. Informational [Page 4]
+
+RFC 3838 OPES Policy Requirements August 2004
+
+
+ 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.
+
+
+
+
+
+Barbir, et al. Informational [Page 5]
+
+RFC 3838 OPES Policy Requirements August 2004
+
+
+ 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.
+
+
+
+Barbir, et al. Informational [Page 6]
+
+RFC 3838 OPES Policy Requirements August 2004
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+Barbir, et al. Informational [Page 7]
+
+RFC 3838 OPES Policy Requirements August 2004
+
+
+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.
+
+
+
+Barbir, et al. Informational [Page 8]
+
+RFC 3838 OPES Policy Requirements August 2004
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+Barbir, et al. Informational [Page 9]
+
+RFC 3838 OPES Policy Requirements August 2004
+
+
+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
+
+ This section considers the authorization and authentication of OPES
+ services.
+
+
+
+
+
+
+
+
+
+Barbir, et al. Informational [Page 10]
+
+RFC 3838 OPES Policy Requirements August 2004
+
+
+5.1. End Users, Publishers and Other Considerations
+
+5.1.1. Considerations for End Users
+
+ 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.
+
+ An OPES service provider MUST satisfy these major requirements:
+
+ o Allow all users to request addition, deletion, or blocking of OPES
+ services for their traffic (blocking means "do not use this
+ service for my traffic").
+ o Prevent untrusted users from causing OPES services to interfere
+ with the traffic of other users.
+ o Allow users to see their OPES service profiles and notify them of
+ changes.
+ o Keep a log of all profile activity for audit purposes.
+ o Adhere to a privacy policy guarding users' profiles.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+Barbir, et al. Informational [Page 11]
+
+RFC 3838 OPES Policy Requirements August 2004
+
+
+5.1.2. Considerations for Publishing Sites
+
+ 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.
+
+5.1.3. Other Considerations
+
+ 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.
+
+5.2. Authentication
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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
+
+
+
+Barbir, et al. Informational [Page 12]
+
+RFC 3838 OPES Policy Requirements August 2004
+
+
+ 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.
+
+5.3. Authorization
+
+ 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.
+
+ 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.
+
+ 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.
+
+ In general, the PDP SHOULD keep its policy base in a manner that
+ makes the decision procedure for all cases easy to understand.
+
+
+
+
+Barbir, et al. Informational [Page 13]
+
+RFC 3838 OPES Policy Requirements August 2004
+
+
+5.4. Integrity and Encryption
+
+5.4.1. Integrity and Confidentiality of Authentication and Requests/
+ Responses for Service
+
+ 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.
+
+5.4.2. Integrity and Confidentiality of Application Content
+
+ 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:
+
+ 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.
+
+5.5. Privacy
+
+ 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.
+
+ Supported limitations MUST include:
+
+ o The ability to prevent Identity from being given to callout
+ servers.
+
+
+
+Barbir, et al. Informational [Page 14]
+
+RFC 3838 OPES Policy Requirements August 2004
+
+
+ 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
+ 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).
+
+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] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An
+ Architecture for Open Pluggable Edge Services (OPES)", RFC 3835,
+ August 2004.
+
+ [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy
+ Considerations for Open Pluggable Edge Services", RFC 3238,
+ January 2002.
+
+ [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.
+
+ [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [5] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen,
+ "Policy Core Information Model -- Version 1 Specification", RFC
+ 3060, February 2001.
+
+7.2. Informative References
+
+ [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.
+
+
+
+
+Barbir, et al. Informational [Page 15]
+
+RFC 3838 OPES Policy Requirements August 2004
+
+
+ [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.
+
+ [8] Christensen, et al., Web Services Description Language (WSDL)
+ 1.1, W3C Note 15 March 2001, http://www.w3.org/TR/wsdl
+
+8. Acknowledgements
+
+ Many thanks to Andreas Terzis, L. Rafalow (IBM), L. Yang (Intel), M.
+ Condry (Intel), Randy Presuhn (Mindspring), and B. Srinivas (Nokia).
+
+9. Authors' Addresses
+
+ Abbie Barbir
+ Nortel Networks
+ 3500 Carling Avenue
+ Nepean, Ontario K2H 8E9
+ Canada
+ Phone: +1 613 763 5229
+ EMail: abbieb@nortelnetworks.com
+
+ Oskar Batuner
+ Consultant
+ EMail: batuner@attbi.com
+
+ Andre Beck
+ Lucent Technologies
+ 101 Crawfords Corner Road
+ Holmdel, NJ 07733
+ USA
+ EMail: abeck@bell-labs.com
+
+ Tat Chan
+ Nokia
+ 5 Wayside Road
+ Burlington, MA 01803
+ USA
+ EMail: Tat.Chan@nokia.com
+
+ Hilarie Orman
+ Purple Streak Development
+ EMail: ho@alum.mit.edu
+
+
+
+
+
+
+
+
+Barbir, et al. Informational [Page 16]
+
+RFC 3838 OPES Policy Requirements August 2004
+
+
+10. Full Copyright Statement
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Barbir, et al. Informational [Page 17]
+