idnits 2.17.1 draft-ietf-opes-authorization-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 46 has weird spacing: '...nts for the s...' == Line 97 has weird spacing: '...he data consu...' == Line 312 has weird spacing: '... define thei...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 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 well-founded cryptographic means, to show that the response is made in reply to a specific request. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 6, 2004) is 7318 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 660, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 673, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 678, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Informational RFC: RFC 3238 (ref. '2') ** Downref: Normative reference to an Informational draft: draft-ietf-opes-threats (ref. '3') -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '6') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Barbir 3 Internet-Draft Nortel Networks 4 Expires: October 5, 2004 O. Batuner 5 Consultant 6 A. Beck 7 Lucent Technologies 8 T. Chan 9 Nokia 10 H. Orman 11 Purple Streak Development 12 April 6, 2004 14 Policy, Authorization and Enforcement Requirements of OPES 15 draft-ietf-opes-authorization-03 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at http:// 32 www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on October 5, 2004. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). All Rights Reserved. 43 Abstract 45 This document describes policy, authorization and enforcement 46 requirements for the selection of the services to be applied to a 47 given OPES flow. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Policy Architecture . . . . . . . . . . . . . . . . . . . . . 5 54 3.1 Policy Components and Functions . . . . . . . . . . . . . 5 55 3.2 Requirements For Policy Decision Point . . . . . . . . . . 6 56 3.3 Requirements for Policy Enforcement Points . . . . . . . . 6 57 4. Requirements for Interfaces . . . . . . . . . . . . . . . . . 8 58 4.1 Service Bindings Requirements . . . . . . . . . . . . . . 8 59 4.1.1 Environment Variables . . . . . . . . . . . . . . . . 8 60 4.1.2 Requirements for Using State Information . . . . . . . 9 61 4.1.3 Requirements for Passing Information Between 62 Services . . . . . . . . . . . . . . . . . . . . . . . 9 63 4.2 Requirements for Rule and Rules Management . . . . . . . . 9 64 4.2.1 Requirements for Rule Providers . . . . . . . . . . . 9 65 4.2.2 Requirements for Rule Formats and Protocols . . . . . 10 66 4.2.3 Requirements for Rule Conditions . . . . . . . . . . . 10 67 4.2.4 Requirements for Rule Actions . . . . . . . . . . . . 10 68 4.3 Requirements for Policy Expression . . . . . . . . . . . . 10 69 5. Authentication of Principals and Authorization of Services . . 12 70 5.1 End users, Publishers and Other Considerations . . . . . . 12 71 5.1.1 Considerations for end users . . . . . . . . . . . . . 12 72 5.1.2 Considerations for publishing sites . . . . . . . . . 13 73 5.1.3 Other considerations . . . . . . . . . . . . . . . . . 13 74 5.2 Authentication . . . . . . . . . . . . . . . . . . . . . . 13 75 5.3 Authorization . . . . . . . . . . . . . . . . . . . . . . 14 76 5.4 Integrity and Encryption . . . . . . . . . . . . . . . . . 15 77 5.4.1 Integrity and confidentiality of authentication 78 and requests/responses for service . . . . . . . . . . 15 79 5.4.2 Integrity and confidentiality of application 80 content . . . . . . . . . . . . . . . . . . . . . . . 15 81 5.5 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 18 85 7.2 Informative References . . . . . . . . . . . . . . . . . . . 18 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 87 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 88 Intellectual Property and Copyright Statements . . . . . . . . 21 90 1. Introduction 92 The Open Pluggable Edge Services (OPES) [1] architecture enables 93 cooperative application services (OPES services) between a data 94 provider, a data consumer, and zero or more OPES processors. The 95 application services under consideration analyze and possibly 96 transform application-level messages exchanged between the data 97 provider and the data consumer. The OPES processor can distribute 98 the responsibility of service execution by communicating and 99 collaborating with one or more remote callout servers. 101 The execution of such services is governed by a set of rules 102 installed on OPES processor. The rule evaluation can trigger the 103 execution of service applications local to the OPES processor or on a 104 remote callout server. 106 Policies express the goals of an OPES processor as a set of rules 107 used to administer, manage and control access to resources. The 108 requirements in this document govern the behavior of OPES entities in 109 determining which, if any, of available services are to be applied to 110 a given message. 112 The scope of OPES policies described in this document are limited to 113 those that describe which services to call and, if appropriate, with 114 what parameters. These policies do not include those that prescribe 115 the behavior of the called services. It is desirable to enable a 116 common management framework for specifying policies for both the 117 calling of and the behavior of a service. The integration of such 118 function is the domain of policy administration user interaction 119 applications. 121 The document is organized as follows:Section 2 considers policy 122 framework. Section 3 discusses requirements for interfaces, while 123 section 4 examines authentication of principals and authorization of 124 services. 126 2. Terminology 128 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [4]. When used with 131 the normative meanings, these keywords will be all uppercase. 132 Occurrences of these words in lowercase comprise normal prose usage, 133 with no normative implications. 135 3. Policy Architecture 137 This section describes the architectural policy decomposition 138 requirements. It also describes the requirements for the interfaces 139 between the policy components. 141 3.1 Policy Components and Functions 143 The policy functions are decomposed into three components: a Rule 144 Author, a Policy Decision Point (PDP) and Policy Enforcement Point 145 (PEP). The Rule Author provides the rules to be used by an OPES 146 entity. These rules control the invocation of services on behalf of 147 the rule author. The PDP and the PEP interpret the collected rules 148 and appropriately enforce them. The decomposition is illustrated in 149 Figure 1. 151 +--------+ +--------+ 152 | Rule | | Rule | 153 | Author | ... | Author | 154 +--------+ +--------+ 155 | | 156 | | 157 | +----------+ | 158 | | Policy | | <- PDP Interface 159 +--------->| Decision |<----------+ 160 | Point | 161 +----------+ 162 | ^ 163 | | 164 | | <- PEP Interface 165 | | 166 V | 167 +--------------+ ... 168 ---> | Policy | ---> 169 | Enforcement | Data Traffic 170 <--- | Point | <--- 171 +--------------+ 173 Figure 1: Policy Components 175 The decomposition of policy control into a PDP and a PEP permit the 176 offloading of some tasks to an administrative service that may be 177 located on a separate server from the real-time enforcement services 178 of the PEP that reside on the OPES processor. 180 The PDP provides for the authentication and authorization of rule 181 authors and the validation and compilation of rules. 183 The PEP resides in the data filter where the data from an OPES flow 184 is evaluated against the compiled rules and appropriate calls to the 185 requested services are performed. 187 Interfaces between these architectural components are points of 188 interoperability. The interface between rule authors and the policy 189 decision points (PDP Interface) MUST use the standard format that may 190 result from the requirements as described in this document. 192 The interface between the policy decision points and the policy 193 enforcement points (PEP Interface) can be internal to a specific 194 vendor implementation of an OPES processor. Implementations MUST use 195 standard interface only if the PDP and the PEP reside on different 196 OPES processor. 198 3.2 Requirements For Policy Decision Point 200 The Policy Decision Point is essentially a policy compiler. The PDP 201 MUST be a service that provides administrative support to the 202 enforcement points. The PDP service MUST authenticate the rule 203 authors. 205 The PDP MUST verify that the specified rules are within the scope of 206 the rule authors authority. The PDP MUST be a component of the OPES 207 Administration Authority. 209 3.3 Requirements for Policy Enforcement Points 211 In the OPES architecture, the data filter represents a Policy 212 Enforcement point (PEP). At this point, data from an OPES flow is 213 evaluated against the compiled rules and appropriate calls to the 214 requested services are performed. 216 In the PEP rules MAY chain actions together, where, a series of 217 services to be called are specified. Implementation MUST ensure the 218 passing of information from one called service to another. 219 Implementation MUST NOT prohibit the re-evaluation of a message to 220 determine if another service or set of services should be called. 222 The execution of an action (i.e., the triggering of a rule) may lead 223 to the modification of a message property values. For example, an 224 OPES service that under some circumstances converts JPEG images to 225 GIF images modifies the content type of the requested web object. 227 Such modification of message property values may change the behavior 228 of subsequently performed OPES actions. The data filter SHOULD act on 229 matched rules before it evaluates subsequent rules. Multiple matched 230 rules can be triggered simultaneously if the data filter can 231 determine in advance that there are no side effects from the 232 execution of any specific rule. 234 A data filter MAY evaluate messages several times in the course of 235 handling an OPES flow. The rule processing points MAY be defined by 236 administratively defined names. The definition of such names can 237 serve as a selector for policy rules to determine the applicability 238 of a rule or a set of rules at each processing point. The scope of 239 policy control of policy roles as defined RFC 3060 SHOULD be used 240 where it aids in the development of the OPES policy model. 242 In Figure 2 a typical message data flow between a data consumer 243 application, an OPES processor and a data provider application. There 244 are four commonly used processing points identified by the numbers 1 245 through 4. 247 +--------+ +-----------+ +---------+ 248 | |<------|4 3|<------| | 249 | Data | | OPES | | Data | 250 |Consumer| | Processor | |Provider | 251 | Appl. |------>|1 2|------>| Appl. | 252 +--------+ +-----------+ +---------+ 254 Figure 2: Processing Execution Points 256 Any data filter (PEP) or any administrative (PDP) implementation MUST 257 support the four rule processing points. 259 o Data Consumer Request Handling Role : This involves request 260 processing when received from a Data Consumer Application. 261 o OPES Processor Request handling role: This involves request 262 processing before forwarding to Data Provider Application. 263 o Data Provider Response handling role: This involves response 264 processing when forwarding to Data Consumer Application. 265 o OPES Processor Response handling role:This involves response 266 processing when forwarding to Data Consumer Application. 268 4. Requirements for Interfaces 270 The interface between the policy system and OPES services needs to 271 include the ability to pass system state information as well as the 272 subject message. 274 4.1 Service Bindings Requirements 276 The invoked OPES services MUST be able to be specified in a location 277 independent fashion. That is, the rule authors need not know and need 278 not specify the instance of an OPES service in the rules. 280 The rule author SHOULD be able to identify the required service at 281 the detail level that is appropriate for his or her needs. The rule 282 author SHOULD be able to specify a type of service or be able to 283 specify any service that fits a general category of service to be 284 applied its traffic. 286 The binding of OPES service names to specific service MAY be 287 distributed between the PDP and the PEP. As rules are compiled and 288 validated by the PDP, they MUST be resolved to a specific 289 installations' set of homogeneous OPES service. 291 The selection of a specific instance MAY be postponed and left to PEP 292 to select at either rule installation time or at run time. To achieve 293 interoperability, PEP MUST support resolving a generic name to a 294 specific instance. It is possible to use services such as SLP or UDDI 295 to resolve generic service names to specific OPES service instances. 297 The policy system MAY support dynamic discovery of service bindings. 298 The rule author may not know specific service bindings such as 299 protocol and parameters, when a rule (as specified on the PDP 300 Interface) is general in nature. The required binding information 301 MUST be provided by the PDP and conveyed on the PEP Interface. A 302 service description methodology such as WSDL MUST be present in the 303 policy system. It is to be determined whether an OPES standard is 304 required. 306 4.1.1 Environment Variables 308 There may be a need to define and support means for maintaining state 309 information that can be used in both condition evaluation and action 310 execution. Depending on the execution environment, OPES services MAY 311 have the freedom to define variables that are needed and use these 312 variables to further define their service behavior without the data 313 filter support. 315 4.1.2 Requirements for Using State Information 317 Policy rules MAY specify that state information be used as part of 318 the evaluation of the rules against a given message in an OPES flow. 319 Thus, the policy system SHOULD support the maintenance of groups that 320 can be used in evaluating rule conditions. Membership in such groups 321 can be used as action triggers. 323 For example, an authorized site blocking service might conclude that 324 a particular user shouldn't be permitted access to a certain web 325 site. Rather than calling the service for each request sent by such a 326 user, a rule might be created that determine if user is a member of 327 blocked users and requested site is a member of blocked-sites then 328 invoke a local blocking service to return and return an appropriate 329 message to the user. 331 4.1.3 Requirements for Passing Information Between Services 333 Environment variables can be used to pass state information between 334 services. For example, analysis of the request or modifications to 335 the request may need to be captured as state information that can be 336 passed to other services on the request path or to services on the 337 response(s) associated with that request. 339 In the PEP, there SHOULD be provisions to enable setting up variables 340 when returning from a service call and passing variables to other 341 called services based on policy. 343 4.2 Requirements for Rule and Rules Management 345 This section provides the requirements for rule management. The rules 346 are divided into two groups. Some rules are provided by the data 347 consumer application and other rules are provided by the data 348 provider application. 350 4.2.1 Requirements for Rule Providers 352 The requirements for rule providers are: 353 o Rule providers MUST be authenticated and authorized for rules that 354 apply to their network role. 355 o Rule providers MUST NOT be able to specify rules that are NOT 356 within their scope of authority. 357 o Rule providers SHOULD be able to specify only what is needed for 358 their services. 359 o Compilation of rules from different sources MUST NOT lead to 360 execution of conflicting rules. 362 o The resolution of such rule conflicts is out of scope 363 o Rules are assumed to be static and applied to current network 364 state. 366 4.2.2 Requirements for Rule Formats and Protocols 368 It is desirable to choose standard technologies like XML to specify 369 the rule language format. 371 Rules need to be sent form the rule authors to the OPES 372 administrative server for service authorization, rule validation and 373 compilation. The mechanisms for doing that are out of scope of the 374 current work. 376 Once the rules are authorized, validated and compiled by the 377 administrative server, the rules need to be sent to the OPES 378 processor. The mechanisms for doing that are out of scope of the 379 current work. 381 4.2.3 Requirements for Rule Conditions 383 Rule conditions MUST be matched against attribute values of the 384 encapsulated protocol as well as environment variable values. 385 Attribute values of the encapsulated protocol include protocol header 386 values and possibly also protocol body values. 388 Some OPES services may need to be invoked for all users requests or 389 server responses, services with logging functionality, as an example. 390 The rule system SHOULD allow unconditional rules rather than 391 requiring rule authors to specify rule conditions that are always 392 true. 394 4.2.4 Requirements for Rule Actions 396 The rule system MUST allow for the specification of rule actions that 397 are triggered if the conditions of a rule are met. Matched rules 398 typically lead to the invocation of local or remote services. Rule 399 actions MUST identify the OPES service that is to be executed for the 400 current message request or response. 402 Rule actions MAY contain run-time parameters which can be used to 403 control the behavior of an OPES service. If specified, these 404 parameters MUST be passed to the executed OPES service. 406 4.3 Requirements for Policy Expression 408 OPES processors MUST enforce policy requirements set by data 409 consumers and/or data publishers in accordance with the architecture 411 [1] and this document. They cannot do this consistently unless there 412 is an unambiguous semantics and representation of the data elements 413 mentioned in the policy. For example, this document mentions 414 protection of user "identity" and "profile" information. If a user 415 specifies that his identity must not be shared with other OPES 416 administrative trust domains and later discovers that his family name 417 has been shared, he might complain. If he were told that "family 418 names are not considered 'identities' by this site", he would 419 probably feel that he had cause for complaint. Or, he might be told 420 that when he selected "do not share identity" on a web form offered 421 by the OPES service provider, that this only covered his login name, 422 and that a different part of the form had to be filled out to protect 423 family name. A further breakdown can occur if the configuration 424 information provided by such a web form gets translated into 425 configuration elements given to an OPES processor, and those 426 configuration elements are difficult for a software engineer to 427 translate into policy enforcement. The data elements might have 428 confusing names or be split into groupings that are difficult to 429 relate to one another. 431 The examples illustrate why OPES policy MUST have definitions of data 432 elements, their relationships, and how they relate to enforcement. 433 These semantics of essential items do not require a separate 434 protocol, but they MUST be agreed upon by all OPES service providers, 435 and the users of OPES services MUST be assured that they have the 436 ability to know their settings, to change them if the service 437 provider policy allows the changes, and to have reasonable assurance 438 that they are enforced with reasonable interpretations. 440 The requirements for policy data elements in the OPES specification 441 do not have to be all-inclusive, but they MUST cover the minimal set 442 of elements that enable the policies that protect the data of end 443 users and publishers. 445 5. Authentication of Principals and Authorization of Services 447 This section considers the authorization and authentication of OPES 448 services. 450 5.1 End users, Publishers and Other Considerations 452 5.1.1 Considerations for end users 454 An OPES rule determines which attributes of traffic will trigger the 455 application of an OPES services. The author of the service can 456 supply rules, but the author cannot supply the necessary part of the 457 rule precondition that determines which network users will have the 458 OPES services applied for them. This section discusses how users are 459 identified in the rule preconditions, and how users can select and 460 deselect OPES services for their traffic, how an OPES service 461 provider SHOULD identify the users, and how they determine whether or 462 not to add their service selection to an OPES enforcement point. 464 An OPES service provider MUST satisfy these major requirements: 465 o Allow all users to request addition, deletion, or blocking of OPES 466 services for their traffic (blocking means "do not use this 467 service for my traffic"). 468 o Prevent untrusted users from causing OPES services to interfere 469 with the traffic of other users. 470 o Allow users to see their OPES service profiles and notify them of 471 changes. 472 o Keep a log of all profile activity for audit purposes. 473 o Adhere to a privacy policy guarding users' profiles. 475 The administrator of the PDP is a trusted party and can set policy 476 for individuals or groups using out-of-band communication and 477 configuration files. However, users MUST always be able to query the 478 PDP in order to learn what rules apply to their traffic. 480 Rules can be deposited in the PDP with no precondition relating to 481 network users. This is the way rules are packaged with an OPES 482 service when it is delivered for installation. The PDP is 483 responsible for binding identities to the rules and transmitting them 484 to the PEP. The identity used by the PDP for policy decisions MUST be 485 strictly mapped to the identity used by the PEP. Thus, if a user 486 goes through and identification and authentication procedure with the 487 PDP and is known by identity "A", and if the PEP uses IP addresses 488 for identities, then the PDP MUST provide the PEP with a binding 489 between "A" and A's current IP address. 491 5.1.2 Considerations for publishing sites 493 An OPES service provider acting on behalf of different publishing 494 sites SHOULD keep all the above considerations in mind when 495 implementing an OPES site. Because each publishing site may be 496 represented by only a single identity, the authentication and 497 authorization databases may be easier for the PEP to handle. 499 5.1.3 Other considerations 501 Authentication may be necessary between PDP's and PEP's, PEP's and 502 callout servers, PEP's and other PEP's, callout servers and other 503 callout servers, for purposes of validating privacy policies. In any 504 case where user data or traffic crosses trust domain boundaries, the 505 originating trust domain SHOULD have a policy describing which other 506 domains are trusted, and it SHOULD authenticate the domains and their 507 policies before forwarding information. 509 5.2 Authentication 511 When an individual selects (or deselects) an OPES service, the 512 individual MUST be authenticated by the OPES service provider. This 513 means that a binding between the user's communication channel and an 514 identity known to the service provider is made in a secure manner. 515 This SHOULD be done using a strong authentication method with a 516 public key certificate for the user; this will be helpful in 517 resolving later disputes. It is recommended that the service 518 provider keep a log of all requests for OPES services. The service 519 provider SHOULD use public key certficates to authenticate responses 520 to requests. 522 The service provider may have trusted users who through explicit or 523 implicit contract can assign, remove, or block OPES services for 524 particular users. The trusted users MUST be authenticated before 525 being allowed to take actions which will modify the policy base, and 526 thus, the actions of the PEP's. 528 Because of the sensitivity of user profiles, the PEP Interface 529 between the PEP and the PDP MUST use a secure transport protocol. The 530 PEP's MUST adhere to the privacy preferences of the users. 532 When an OPES service provider accepts an OPES service, there MUST be 533 a unique name for the service provided by the entity publishing the 534 service. Users MAY refer to the unique name when requesting a 535 service. The unique name MUST be used when notifying users about 536 their service profiles. PEP's MUST be aware of the unique name for 537 each service that can be accessed from their domain. There MUST be a 538 cryptographic binding between the unique name and the entity 539 responsible for the functional behavior of the service; i.e., if it 540 is a human language translating service then the name of company that 541 wrote the software SHOULD be bound to the unique name. 543 5.3 Authorization 545 In addition to requesting or terminating specific services, users MAY 546 block particular services, indicating that the services should not be 547 applied to their traffic. The "block all OPES" directive MUST be 548 supported on a per user basis. 550 A response to a request for an OPES service can be positive or 551 negative. Reasons for a negative response include "service unknown" 552 or "service denied by PDP policy". Positive responses SHOULD include 553 the identity of the requestor and the service and the type of 554 request. 556 As described in the OPES Architecture [1], requests for OPES services 557 originate in either the enduser or the publisher domain. The PDP 558 bases its authorization decision on the requestor and the domain. 559 There are some cases where the decision may be complicated. 560 o The end user has blocked a service, but a trusted user of the PDP 561 wants it applied anyway. In this case, the end user SHOULD 562 prevail, unless their are security or legal reasons to leave it in 563 place. 564 o The publisher and the enduser are in the same domain. If the 565 publisher and enduser are both clients of a PDP, can they make 566 requests that effect each other's processing? In this case, the 567 PDP MUST have policy rules naming the identities that are allowed 568 to set such rules. 569 o The publisher requests a service for an enduser. In this case, in 570 which the PDP and PEP are in the publisher's administrative 571 domain, the publisher has some way of identifying the end user and 572 his traffic, and the PDP MUST enable the PEP to enforce the 573 policy. This is allowed, but the PDP MUST use strong methods to 574 identify the user and his traffic. The user MUST be able to 575 request and receive information about the service profile that a 576 publisher site keeps about him. 577 o The enduser requests a service specific to a publisher identity 578 (e.g., nfl.com), but the publisher prohibits the service (e.g., 579 through a "NO OPES" application header). As in the case above, 580 the publisher MUST be able to request and receive profile 581 information that a user keeps about a publisher. 583 In general, the PDP SHOULD keep its policy base in a manner that 584 makes the decision procedure for all cases easy to understand. 586 5.4 Integrity and Encryption 588 5.4.1 Integrity and confidentiality of authentication and requests/ 589 responses for service 591 The requests and responses SHOULD be cryptographically tied to the 592 identities of the requestor and responder, and the messages SHOULD 593 not be alterable without detection. A certificate-based digital 594 signature is strongly recommended as part of the authentication 595 process. A binding between the request and response SHOULD be 596 established using well-founded cryptographic means, to show that the 597 response is made in reply to a specific request. 599 5.4.2 Integrity and confidentiality of application content 601 As directed by the PEP, content will be transformed in whole or in 602 part by OPES services. This means that end-to-end cryptographic 603 protections cannot be used. This is probably acceptable for the vast 604 majority of traffic, but in cases where a lesser form of content 605 protection is desirable, hop-by-hop protections can be used instead. 606 The requirements for such protections are: 607 o Integrity using shared secrets MUST be used between all processing 608 points, end-to-end (i.e., the two ends a "hop" MUST share a 609 secret, but the secret can be different between "hops"). The 610 processing points include the callout servers. 611 o Encryption can be requested separately, with the same secret 612 sharing requirement between "hops". When requested, encryption 613 applies to all processing points, including callout servers. 614 o The signal for integrity (and optionally encryption) MUST 615 originate from either the requestor (in which case it is applied 616 to the response as well) or the responder (in which case it covers 617 only the response). 618 o The shared secrets MUST be unique (to within a very large 619 probabilistic certainty) for each requestor/responder pair. This 620 helps to protect the privacy of enduser data from insider attacks 621 or configuration errors while it transits the provider's network. 623 5.5 Privacy 625 The PDP MUST have a privacy policy regarding OPES data such as user 626 profiles for services. Users MUST be able to limit the promulgation 627 of their profile data and their identities. 629 Supported limitations MUST include: 630 o The ability to prevent Identity from being given to callout 631 servers. 633 o The ability to prevent Profile information from being shared. 634 o The ability to prevent Traffic data from being sent to callout 635 servers run by third parties. 636 o The ability to prevent Traffic from particular sites from being 637 given to OPES callout servers. 639 When an OPES service is provided by a third-party, it MUST have a 640 privacy policy and identify itself to upstream and downstream 641 parties, telling them how to access its privacy policy. A mechanism 642 is needed to specify these preferences and a protocol to distribute 643 that (see section 3.3). 645 6. Security Considerations 647 This document discusses policy, authorization and enforcement 648 requirements of OPES. In [3] multiple security and privacy issues 649 related to the OPES services are discussed. 651 7. References 653 7.1 Normative References 655 [1] A. Barbir et. al, "An Architecture for Open Pluggable Edge 656 Services (OPES)", Internet-Draft: http://www.ietf.org/ 657 internet-drafts/draft-ietf-opes-architecture-04.txt, December 658 2002. 660 [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy 661 Considerations for Open Pluggable Edge Services", RFC 3238, 662 January 2002. 664 [3] Barbir et. al, A., "Security Threats and Risks for OPES", 665 Internet-Draft: http://www.ietf.org/internet-drafts/ 666 draft-ietf-opes-threats-03.txt, December 2003. 668 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 669 Levels", RFC 2119, March 1997. 671 7.2 Informative References 673 [5] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., 674 Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. 675 Waldbusser, "Terminology for Policy-Based Management", RFC 3198, 676 November 2001. 678 [6] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 679 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 680 HTTP/1.1", RFC 2616, June 1999. 682 Authors' Addresses 684 Abbie Barbir 685 Nortel Networks 686 3500 Carling Avenue 687 Nepean, Ontario K2H 8E9 688 Canada 690 Phone: +1 613 763 5229 691 EMail: abbieb@nortelnetworks.com 692 Oskar Batuner 693 Consultant 695 EMail: batuner@attbi.com 697 Andre Beck 698 Lucent Technologies 699 101 Crawfords Corner Road 700 Holmdel, NJ 07733 701 USA 703 EMail: abeck@bell-labs.com 705 Tat Chan 706 Nokia 707 5 Wayside Road 708 Burlington, MA 01803 709 USA 711 EMail: Tat.Chan@nokia.com 713 Hilarie Orman 714 Purple Streak Development 716 Phone: 717 EMail: ho@alum.mit.edu 719 Appendix A. Acknowledgements 721 Many thanks to Andreas Terzis, L. Rafalow (IBM), L. Yang (Intel), M. 722 Condry (Intel), Randy Presuhn (Mindspring) and B. Srinivas (Nokia) 724 Intellectual Property Statement 726 The IETF takes no position regarding the validity or scope of any 727 intellectual property or other rights that might be claimed to 728 pertain to the implementation or use of the technology described in 729 this document or the extent to which any license under such rights 730 might or might not be available; neither does it represent that it 731 has made any effort to identify any such rights. Information on the 732 IETF's procedures with respect to rights in standards-track and 733 standards-related documentation can be found in BCP-11. Copies of 734 claims of rights made available for publication and any assurances of 735 licenses to be made available, or the result of an attempt made to 736 obtain a general license or permission for the use of such 737 proprietary rights by implementors or users of this specification can 738 be obtained from the IETF Secretariat. 740 The IETF invites any interested party to bring to its attention any 741 copyrights, patents or patent applications, or other proprietary 742 rights which may cover technology that may be required to practice 743 this standard. Please address the information to the IETF Executive 744 Director. 746 Full Copyright Statement 748 Copyright (C) The Internet Society (2004). All Rights Reserved. 750 This document and translations of it may be copied and furnished to 751 others, and derivative works that comment on or otherwise explain it 752 or assist in its implementation may be prepared, copied, published 753 and distributed, in whole or in part, without restriction of any 754 kind, provided that the above copyright notice and this paragraph are 755 included on all such copies and derivative works. However, this 756 document itself may not be modified in any way, such as by removing 757 the copyright notice or references to the Internet Society or other 758 Internet organizations, except as needed for the purpose of 759 developing Internet standards in which case the procedures for 760 copyrights defined in the Internet Standards process must be 761 followed, or as required to translate it into languages other than 762 English. 764 The limited permissions granted above are perpetual and will not be 765 revoked by the Internet Society or its successors or assignees. 767 This document and the information contained herein is provided on an 768 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 769 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 770 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 771 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 772 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 774 Acknowledgment 776 Funding for the RFC Editor function is currently provided by the 777 Internet Society.