This section considers the authorization and authentication of OPES
services.
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.
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
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.
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.
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.
[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
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.