draft-ietf-cdi-scenarios

[hardie@qualcomm.com]

At the last IETF meeting, this draft was approved as an informational
RFC, subject to my checking on that status of a document it references
in the security considerations (since Steve had agreed to the existing
security considerations only because they referenced a larger, more
fully worked set).  As it turns out, the group no longer intends to complete
the document which was referenced (indeed, the group is on the list to
be closed for lack of energy, and this draft is going out just to document
what it did manage to accomplish).  After discussion with the draft authors
and Chair, I believe the right answer here is to send an RFC editor note
which replaces the existing security considerations with those from
the referenced architecture draft.  This will eliminate the reference to
the existing draft, so the document does not hang in the queue waiting
for a document which will never arrive.

This is a pretty big update for an RFC editor note, but this seems like
the most likely way forward.  Given the size, though, I plan to bash
Thursday's agenda to get a quick thumbs-up or thumbs-down on
this plan.

With the approval of the group, I plan to send the following to the IESG
secretary for transmission to the RFC Editor:

Please update the text of draft-ietf-cdi-scenarios, recently approved as
an informational RFC, so that the reference to draft-ietf-cdi-architecture is
removed entirely and the existing Security Considerations section
is removed and replaced with:

5. Security Considerations

   Security concerns with respect to Content Internetworking can be
   generally categorized into trust within the system and protection of
   the system from threats. The trust model utilized with Content
   Internetworking is predicated largely on transitive trust between
   the ORIGIN, REQUEST-ROUTING PEERING SYSTEM, DISTRIBUTION PEERING
   SYSTEM, ACCOUNTING PEERING SYSTEM and SURROGATES.  Network elements
   within the Content Internetworking system are considered to be
   "insiders" and therefore trusted.

5.1 Threats to Content Internetworking

   The following sections document key threats to CLIENTs, PUBLISHERs,
   and CNs. The threats are classified according to the party that they
   most directly harm, but, of course, a threat to any party is
   ultimately a threat to all. (For example, having a credit card
   number stolen may most directly affect a CLIENT; however, the
   resulting dissatisfaction and publicity will almost certainly cause
   some harm to the PUBLISHER and CN, even if the harm is only to those
   organizations' reputations.)

5.1.1 Threats to the CLIENT

5.1.1.1 Defeat of CLIENT's Security Settings

   Because the SURROGATE's location may differ from that of the ORIGIN,
   the use of a SURROGATE may inadvertently or maliciously defeat any
   location-based security settings employed by the CLIENT. And since
   the SURROGATE's location is generally transparent to the CLIENT, the
   CLIENT may be unaware that its protections are no longer in force.
   For example, a CN may relocate CONTENT from a Internet Explorer
   user's "Internet Web Content Zone"  to that user's "Local Intranet
   Web Content Zone." If the relocation is visible to the Internet
   Explorer browser but otherwise invisible to the user, the browser
   may be employing less stringent security protections than the user
   is expecting for that CONTENT. (Note that this threat differs, at
   least in degree, from the substitution of security parameters threat
   below, as Web Content Zones can control whether or not, for example,
   the browser executes unsigned active content.)

5.1.1.2 Delivery of Bad Accounting Information

   In the case of CONTENT with value, CLIENTs may be inappropriately
   charged for viewing content that they did not successfully access.
   Conversely, some PUBLISHERs may reward CLIENTs for viewing certain
   CONTENT (e.g. programs that "pay" users to surf the Web). Should a
   CN fail to deliver appropriate accounting information, the CLIENT
   may not receive appropriate credit for viewing the required CONTENT.



5.1.1.3 Delivery of Bad CONTENT

   A CN that does not deliver the appropriate CONTENT may provide the
   user misleading information (either maliciously or inadvertently).
   This threat can be manifested as a failure of either the
   DISTRIBUTION SYSTEM (inappropriate content delivered to appropriate
   SURROGATEs) or REQUEST-ROUTING SYSTEM (request routing to
   inappropriate SURROGATEs, even though they may have appropriate
   CONTENT), or both. A REQUEST-ROUTING SYSTEM may also fail by
   forwarding the CLIENT request when no forwarding is appropriate, or
   by failing to forward the CLIENT request when forwarding is
   appropriate.

5.1.1.4 Denial of Service

   A CN that does not forward the CLIENT appropriately may deny the
   CLIENT access to CONTENT.

5.1.1.5 Exposure of Private Information

   CNs may inadvertently or maliciously expose private information
   (passwords, buying patterns, page views, credit card numbers) as it
   transits from SURROGATEs to ORIGINs and/or PUBLISHERs.

5.1.1.6 Substitution of Security Parameters

   If a SURROGATE does not duplicate completely the security facilities
   of the ORIGIN (e.g. encryption algorithms, key lengths, certificate
   authorities) CONTENT delivered through the SURROGATE may be less
   secure than the CLIENT expects.

5.1.1.7 Substitution of Security Policies

   If a SURROGATE does not employ the same security policies and
   procedures as the ORIGIN, the CLIENT's private information may be
   treated with less care than the CLIENT expects. For example, the
   operator of a SURROGATE may not have as rigorous protection for the
   CLIENT's password as does the operator of the ORIGIN server. This
   threat may also manifest itself if the legal jurisdiction of the
   SURROGATE differs from that of the ORIGIN, should, for example,
   legal differences between the jurisdictions require or permit
   different treatment of the CLIENT's private information.

5.1.2 Threats to the PUBLISHER

5.1.2.1 Delivery of Bad Accounting Information

   If a CN does not deliver accurate accounting information, the
   PUBLISHER may be unable to charge CLIENTs for accessing CONTENT or
   it may reward CLIENTs inappropriately. Inaccurate accounting
   information may also cause a PUBLISHER to pay for services (e.g.
   content distribution) that were not actually rendered.) Invalid
   accounting information may also effect PUBLISHERs indirectly by, for
   example, undercounting the number of site visitors (and, thus,
   reducing the PUBLISHER's advertising revenue).

5.1.2.2 Denial of Service

   A CN that does not distribute CONTENT appropriately may deny CLIENTs
   access to CONTENT.

5.1.2.3 Substitution of Security Parameters

   If a SURROGATE does not duplicate completely the security services
   of the ORIGIN (e.g. encryption algorithms, key lengths, certificate
   authorities, client authentication) CONTENT stored on the SURROGATE
   may be less secure than the PUBLISHER prefers.

5.1.2.4 Substitution of Security Policies

   If a SURROGATE does not employ the same security policies and
   procedures as the ORIGIN, the CONTENT may be treated with less care
   than the PUBLISHER expects. This threat may also manifest itself if
   the legal jurisdiction of the SURROGATE differs from that of the
   ORIGIN, should, for example, legal differences between the
   jurisdictions require or permit different treatment of the CONTENT.

5.1.3 Threats to a CN

5.1.3.1 Bad Accounting Information

   If a CN is unable to collect or receive accurate accounting
   information, it may be unable to collect compensation for its
   services from PUBLISHERs.

5.1.3.2 Denial of Service

   Misuse of a CN may make that CN's facilities unavailable, or
   available only at reduced functionality, to legitimate customers or
   the CN provider itself. Denial of service attacks can be targeted at
   a CN's ACCOUNTING SYSTEM, DISTRIBUTION SYSTEM, or REQUEST-ROUTING
   SYSTEM.

5.1.3.3 Transitive Threats

   To the extent that a CN acts as either a CLIENT or a PUBLISHER (such
   as, for example, in transitive implementations) such a CN may be
   exposed to any or all of the threats described above for both roles.














































Green, et. a