Subject: OPES security issues (was Re: OPES BOF....)

From: "James P. Salsman" <[email-masked]>
Date: Tue, 17 Apr 2001 21:08:59 -0700 (PDT)

Michael,

Thank you for your twenty-two octet reply:

> see www.ietf-opes.org

Clearly, I already did see that, as evidenced in the message to which 
you were replying: 

> At 07:43 PM 4/13/2001 -0700, you wrote:
> > >... tell us what OPES and BCDF are...
> >
> >In  http://www.ietf-opes.org/Default.htm  :
       ^^^^^^^^^^^^^^^^^^^^^^^^
> >]
> >] The Open Pluggable Edge Services architecture (OPES) is defines [sic]....

However, I went back and re-read all the drafts as well as the charter
and introduction, and the question remains.  You seem to be intent on 
defining an architecture which would facilitate remote evesdropping.  

Here are some comments on the drafts:

draft-beck-opes-esfnep-01.txt -- this draft has no security 
considerations section, even though security concerns are addressed 
in the context of automated virus scanning, as a motivation.

draft-tomlinson-epsfw-01.txt -- this draft has expired, and the link 
on www.ietf-opes.org points to the expiration notice.  There is no 
subsequent version in the Internet Drafts directory.  A Google search
on "draft-tomlinson-epsfw" finds the -00.txt version which has a 
lengthy security considerations section which only specifies some
requirements for security, but not methods to implement them.  Later 
in the draft (outside the security requirements section) this quote 
appears:  "If the caching proxy continues to remain largely 
transparent as a interception proxy, the possibility for abuse is 
high.  Therefore, setting up a value added caching proxy without a 
business (or other social) relationship between either the client or 
the server (or both), is a highly unethical act.  Clients and servers 
are encouraged to use authentication to limit their vulnerability to 
unauthorized intermediate processing on caching proxy. Value added 
providers are encouraged to advertise the presence of value added 
services, so that clients know that their Web streams are being 
modified." Then, this statement is supplied without any further 
analysis:  "Value added caching proxies have a potential to reduce 
the processing transparency of the Web, but their commercial 
potential, and thus the value they provide both to publishers and 
clients, is still higher."  Where is the support for that claim?

draft-elson-opes-icap-01.txt -- this draft has a three-part security 
considerations section.  The first part specifies Basic and Digest 
Access HTTP Authentication MUST be used for the proxy servers being 
described. The second part mentions, "eavesdroppers may be able to 
record the unencrypted transactions between ICAP clients and servers"
which is interesting given that if they are able to do so, then they 
are able to defeat the RFC 2617 Basic and Digest Authentication 
required by the first section.  The third part complains about how 
difficult the validation of ICAP services will be.  This is one of 
the more amusing yet disturbing security considerations sections I 
have read in a long time.

draft-beck-opes-irml-00.txt -- this draft claims that security 
considerations are beyond its scope, but "it is clearly necessary 
to define a secure mechanism...."  Great.

draft-yang-opes-rule-processing-service-execution-00.txt -- this 
draft merely refers to the security considerations section of the 
expired draft-tomlinson-epsfw-01.txt draft above.

draft-maciocco-opes-omml-00.txt -- "7. Security Considerations:
Although beyond the scope of this document, it is clearly necessary 
to define a secure mechanism...."

draft-erickson-opes-taxonomy-00.txt -- This draft has no security 
considerations section.  It does, however, list these possible uses 
for OPES:  "Request Filtering through Content Analysis", "Creation 
of User Profiles", "Insertion of Ad Banners", and others.

Many of the drafts do admit that the services they provide will 
only work for unencrypted content.  Others make no mention of that.

This reminds me of how Microsoft wanted Outlook to be scriptable 
for the added "features" that ended up being abused far more than 
they were legitimatly used.  There probably never was an actual 
cost-benefit analysis.  Has anyone in the OPES group published an 
analysis of the potential value added versus the potential risks?

Cheers,
James