OPES security issues (was Re: OPES BOF....)
"James P. Salsman" <bovik@best.com> Wed, 18 April 2001 04:10 UTC
Received: by ietf.org (8.9.1a/8.9.1a) id AAA22935 for ietf-outbound.10@ietf.org; Wed, 18 Apr 2001 00:10:02 -0400 (EDT)
Received: from shell9.ba.best.com (root@[206.184.139.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA22912 for <ietf@ietf.org>; Wed, 18 Apr 2001 00:09:19 -0400 (EDT)
Received: (from bovik@localhost) by shell9.ba.best.com (8.9.3/8.9.2/best.sh) id VAA17379; Tue, 17 Apr 2001 21:08:59 -0700 (PDT)
Date: Tue, 17 Apr 2001 21:08:59 -0700
From: "James P. Salsman" <bovik@best.com>
Message-Id: <200104180408.VAA17379@shell9.ba.best.com>
To: condry@intel.com
Subject: OPES security issues (was Re: OPES BOF....)
Cc: ietf-openproxy@IMC.ORG, ietf@ietf.org
In-Reply-To: <5.0.2.1.2.20010416092631.048d06d8@FMSMSX63.fm.intel.com>
X-Loop: ietf@ietf.org
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
- OPES security issues (was Re: OPES BOF....) James P. Salsman