[Top] [All Lists]

Notes on a threat and trust model

2002-03-26 17:38:32

Here's a start on the notions of threat and trust in OPES; it's
a first cut, may have significant lacunae.  For discussion.


An OPES system has the responsibility of delivering data that is an
accurate representation of what the publisher wants, what content
enhancement systems can provide, and what end users want to see.

In existing systems, end users may have their requests subject to
filtering, either by choice or because their access provider (e.g.,
employer or school) requires access control.  Typically, the access
control lists are provided by third parties.  The proxy is responsible
for invoking filtering on the requests that require it, usually by
identifying the user and his privileges, for accurately communicating
the requested item to the filtering system, and for accurately
enforcing the action that corresponds to the filtering result
(e.g. "deny" will turn into an HTTP error message).  In addition, the
proxy must get updates of the filtering lists and/or software in a
timely manner.

Similary, proxies operating on behalf of web site owners may engage in
access control decisions and enforcement, timed release of data, etc.
The responsibility of the proxy is to accurately enforce the web site
owner's policies.

OPES systems also have these responsibilities, but they must also
apply content enhancement functions.  These may be simple or
complicated.  They must not introduce errors into content without
errors, they should not violate publisher or end user policies.

Threats come in a few classes, with some overlap. The classes are:

 - errors that decrease the quality of the user experience
   (as compared to non-modified content)
 - privacy violations
 - access control violations
 - malicious content introduction
 - content misattribution, leading to loss of ownership information or so
   as to alter trust decisions made by participants

More specifically, an improper OPES intermediary could
  -  get the wrong policy for a user or web site
  -  send data to the wrong callout server, one that is
  -  introduce pathways for denial of service attacks
  -  introduce errors that appeared to come from another party
  -  violate privacy or confidentiality
     (e.g., by caching data that should only be delivered once, or
     by confusing variants of objects)
  -  give confidential data to a callout server (or other party, such
     as an accounting service) that is outside the
     trust boundary of the end user or publisher
  -  be induced to add malicious content
  -  communiate with an authorization server that is
  -  obscure the origin of data, inducing trust by the enduser
     that was not warranted
  -  mishandle authentication information
  -  erase copyright notices
  -  alter information that is essential for authentication
  -  mislabel environment information that is needed by a callout
  -  assist in masquerading by malicious parties
  -  facilitate lurking and looming

We turn to the question of how parties establish trust and use the
trust relationships to mitigate risk.

1. Authorization and authentication and policy servers must be trusted by the
   OPES intermediary.  There must be a sound basis for its identication
   of trusted servers and the communication with them.

2. Mapping content and actions to subjects.  There must be a way to
   identify end users, publishers, and special administrators in order
   to apply policy relating to them correctly.  This does not mean
   that the OPES intermediary must know personal information about a
   user, but it must be able to associate content traffic with the
   policy rules for the generator of the traffic.

   Subjects may include:
   a. end users
   b. representatives of end users
   c. publishers
   d. representatives of publishers
   e. providers of software performing OPES functions
   f. providers of policy for OPES intermediaries
   g. service vendor for callout server
   h. accounting service
   i. OPES configuration server
   j. OPES administrator
   k. OPES operator
   l. other OPES intermediaries

3. Authentication of policy information relating to content requestors
   and responders.  An OPES intermediary may receive policy
   information from a policy server, from an end user, from a
   publisher, through a new protocol, or through content extensions.
   In all cases, it must have a well-founded way of determining that the
   policy is from a party iwth authority to set policy.

4. Site policy.  The intermediary must have a policy regarding the
   acceptance of policy rules.  For example, some sites will not allow
   users to remove restrictions, but they will allow them to add

5. Enforcement of user confidentiality requirements.  There must be a
   privacy policy and it must be honored.

6. Enforcement of publisher access control policy.

7. Delegation of authority by end user or publisher

8. Content policy.
   a. do not modify
   b. apply only language or device translation services
   c. apply services signed by designated authorities
   d. do not use callout servers run by list of authorities
   e. alert publisher of content rejection
   f. do not apply list of services
   g. must apply list of services
   h. do not report usage
   i. report usage
   j. must add link to non-modified content
   k. do not replace url's
   l. maintain content trace (content traceroute)
   m. do not add scripts
   n. do not introduce any URI's naming new parties

<Prev in Thread] Current Thread [Next in Thread>