[Top] [All Lists]

OPES and content path security

2002-03-11 13:18:59

Listed below are the relevant excerpts from the IAB RFC 3238 on OPES
considerations on the subject of encryption.  I'd like to solicit
comments on these topics.  I think it would help to begin with a
simple security model.

Encryption, for this discussion, is a mechanism for protecting
the privacy of material on an open communication channel.  In order
to discuss privacy for OPES-handled content, we need to understand
the parties who have a stake in the privacy.  If the privacy is
between the content publisher and the end-user, and both parties
believe they have a stake in that privacy, then neither should delegate
their rights, and they should use an end-to-end authentication and
encryption protocol that prevents any intermediary from seeing
the content.  OPES is "compatible" with that notion of end-to-end
encryption in the sense that it does not prevent such usage.

I'd like to call the end-user and the publisher the primary parties
for the trust model.  The publisher may not actually be in the
end-to-end path, and I think there are cases where the end-user
isn't there either, at least immediately, but eventually there either
will be an end user involved in the protocol or else the content is
irrelevant for our purposes here.

The trust becomes more complicated if the parties can delegate
their rights.  I think that the IAB considerations are assuming
that the initial parties can delegate some aspects of their
data privacy to third parties, as in the case of a publisher delegating
privacy to a content delivery service, but it also considers further
delegation of privacy along the delivery path.  The mechanism for
this is "hop-by-hop" or "link" encryption.  I believe that RFC3238
means to say that link encryption is "compatible" with end-to-end
encryption if all IP-address-terminated links use encryption
and there is a well-founded delegation path for each link.  This
introduces the intermediaries as new parties to the security model.
These intermediaries may be trusted for some functions, but not
others.  True end-to-end encryption should be used by the primary
parties for data for which intermediaries are not trusted; some
intermediaries may impose this themselves.

We may want to extend the notion above to encompass callout
servers, but I'm not sure.

A topic for discussion, I believe, is whether or not "transparent"
delegation is allowed, and if not, how fine-grained should the
delegation policy be, i.e., should each primary party be aware of all
delegations, should one party be aware, should each party require
explicit approval for all delegations, etc.

Should the OPES callout servers be visible parts of the delegation

In the consideration 2.2 below, it appears to me that that the only
OPES intermediaries permitted would be one "hop" away from the end-user,
effectively preventing any publisher-authorized intermediaries.
Further, while this language would seem to preclude chained
intermediaries, later language specfically overrides this notion,
apparently allowing trusted chains of intermediaries, possibly without
explicit trust relationships (?).

I would like to solicit help on interpreting the sentence below about
services requiring data in the clear.

=== excerpts from RFC 3238 ==========

  ... the OPES working group will also have to
    explicitly decide and document whether the OPES architecture must be
    compatible with the use of end-to-end encryption by one or more ends
    of an OPES-involved session.  If OPES was compatible with end-to-end
    encryption, this would effectively ensure that OPES boxes would be
    restricted to ones that are known, trusted, explicitly addressed at
    the IP layer, and authorized (by the provision of decryption keys) by
    at least one of the ends.  Compatibility with end-to-end encryption
    would also help to prevent the widespread deployment of yet another
    set of services that, to benefit from, require one to keep one's
    packet contents in the clear for all to snoop.

(2.1) One-party consent: An OPES framework standardized in the IETF
    must require that the use of any OPES service be explicitly
    authorized by one of the application-layer end-hosts (that is, either
    the content provider or the client).

(2.2) IP-layer communications: For an OPES framework standardized in
    the IETF, the OPES intermediary must be explicitly addressed at the
    IP layer by the end user.

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