From owner-ietf-openproxy@mail.imc.org  Wed Oct  2 16:59:11 2002
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07742
	for <opes-archive@ietf.org>; Wed, 2 Oct 2002 16:59:10 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g92KRqu13313
	for ietf-openproxy-bks; Wed, 2 Oct 2002 13:27:52 -0700 (PDT)
Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g92KRpv13309
	for <ietf-openproxy@imc.org>; Wed, 2 Oct 2002 13:27:51 -0700 (PDT)
Received: from frejya.corp.netapp.com (frejya [10.10.20.91])
	by mx01-a.netapp.com (8.12.3/8.12.3/NTAP-1.4) with ESMTP id g92KRjl7009146;
	Wed, 2 Oct 2002 13:27:45 -0700 (PDT)
Received: from ussvlexc01.corp.netapp.com (ussvlexc01.corp.netapp.com [10.10.22.169])
	by frejya.corp.netapp.com (8.12.5/8.12.2/NTAP-1.4) with ESMTP id g92KRYnj025608;
	Wed, 2 Oct 2002 13:27:35 -0700 (PDT)
Received: by ussvlexc01.corp.netapp.com with Internet Mail Service (5.5.2653.19)
	id <QPB05N79>; Wed, 2 Oct 2002 13:27:34 -0700
Message-ID: <6440EA1A6AA1D5118C6900902745938E5772CB@black.eng.netapp.com>
From: "Merrick, Jeffrey" <Jeffrey.Merrick@netapp.com>
To: "'Markus Hofmann'" <markus@mhof.com>,
        Geetha Manjunath
	 <geetham@india.hp.com>
Cc: OPES Group <ietf-openproxy@imc.org>
Subject: RE: OPES Status Update, Drafts, ICAP
Date: Wed, 2 Oct 2002 13:27:31 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


> I can see and agree that the "preview" mechanism is quite useful
> in several secnarios. However, it requires that the preview size
> is statically agreed on a-priori. I could imagine that there are 
> services that can deliver a final response before receiving the
> entire message, but without knowing how many bytes (i.e. preview
> size) they need to see before being able to do so. 

An ICAP server is allowed by the ICAP internet draft to reply to an
ICAP client before the ICAP server has received the entire encapsulated
body. In fact, ICAP servers are encouraged to produce such "incremental" responses in order to reduce latency, which is important when a request
has to be processed by multiple ICAP servers.  These are some of the
reasons the ICAP internet draft gives in section 8.2 for mandating the
use of chunked encoding for ICAP encapsulated bodies.

Consequently, ICAP clients should be written to check for an ICAP server's
response while the ICAP client is sending out the encapsulated body.
Unfortunately, I don't think this point about ICAP clients is mentioned
explicitly in the internet draft.

Jeff


From owner-ietf-openproxy@mail.imc.org  Thu Oct  3 22:22:02 2002
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11420
	for <opes-archive@ietf.org>; Thu, 3 Oct 2002 22:22:01 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g941q3f03716
	for ietf-openproxy-bks; Thu, 3 Oct 2002 18:52:03 -0700 (PDT)
Received: from linux.royaleng.com (linux.royaleng.com [216.83.131.67])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g941q1v03709
	for <ietf-openproxy@imc.org>; Thu, 3 Oct 2002 18:52:01 -0700 (PDT)
Received: from localhost.localdomain (pl109438.fiber.net [216.83.152.26] (may be forged))
	by linux.royaleng.com (8.11.2/8.11.2) with ESMTP id g941tLg08715
	for <ietf-openproxy@imc.org>; Thu, 3 Oct 2002 19:55:21 -0600
Received: (from ho@localhost)
	by localhost.localdomain (8.11.6/8.11.6) id g941nZA03058;
	Thu, 3 Oct 2002 19:49:35 -0600
Date: Thu, 3 Oct 2002 19:49:35 -0600
Message-Id: <200210040149.g941nZA03058@localhost.localdomain>
From: "The Purple Streak, Hilarie Orman" <ho@alum.mit.edu>
To: ietf-openproxy@imc.org
Subject: Conference relevant to OPES
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


If you're working on an OPES paper, this might be a good conference to
submit it to.

Hilarie

-----------------------------------------------------------------------

The Sixth IEEE Conference on Open Architectures and Network Programming
                      (Co-Located with INFOCOM 2003)
                             April 4-5, 2003
                            San Francisco, CA
                     Evolving Future Network Services
                             Call for Papers

The Sixth IEEE Conference on Open Architectures and Network
Programming (OPENARCH) will focus software and hardware technologies
required to facilitate the evolution of the Internet to better support
new services.  OPENARCH is an international forum with a single-track
format that provides researchers and developers with a focused, highly
interactive opportunity to present and discuss current work and future
directions in network services, and in open, programmable network
architectures.

Open and programmable networking is driven by the desire to allow the
Internet to continue its rapid evolution whilst becoming the commercial
network infrastructure of choice.  However, over the last decade
technological advances have led the network infrastructure to become
more complex rather than less (multiple technologies, protocols and
topological layers), obstructing the introduction of new network
services. Over the last few years the open and programmable networking
community has redefined the basic architecture of networking systems
and has blurred the distinctions between routers and end-systems. At
the same time, new services, such as p2p systems, have become
immensely popular; they pose significant challenges for network
providers and impose new requirements on the underlying infrastructure.

The goal of OPENARCH 2003 is to move forward the discussion and
understanding of these issues in networking systems, network services
and wide-area service deployment. We solicit submission of high quality
original research in these areas, with emphasis on implementations and
experimentation. Authors are invited to submit full papers for
consideration. Suggested topics include:

     * Active and programmable networks
     * Hardware and software implementation techniques
     * Modeling of network services in open network architectures
     * New network services and applications
     * Overlay, virtual, and peer-to-peer networks
     * Programming for pricing, accounting, and billing
     * Proxies, middleboxes, and mediation devices
     * Reliability of programmable networking technologies
     * Security in an open networks and distributed applications
     * Service creation platforms and enabling technologies

Instructions for Authors

Papers must be formatted according to the IEEE standard double-column
format.  All papers must be in the 11pt font.  Please note:
submissions longer than 9 pages will not be reviewed.  Authors are
requested to submit papers in the Adobe Portable Document Format
(PDF).  Instructions for electronic submissions are available at:
http://www.openarch.org .

Accepted paper(s) will be published in a bound Conference
Proceedings. A CD-ROM version will be available as well.

Deadlines
Deadline for registration of papers    November 10th, 2002
Deadline for receipt of papers         November 17th, 2002
Notification of acceptance mailed      January   5th, 2003
Final camera-ready papers due          January  17th, 2003

Financial Support
We expect a limited number of travel stipends to be available. Students
whose papers are accepted and who will present the paper themselves are
encouraged to apply if such assistance is needed. Requests for stipends
should be addressed to the General Chair. A limited number of IEEE
Communications Society Student Travel Grants may be available for
student authors from outside North America.

Organizing Committee
General Chair:  Simon Crosby, CPlane Inc.
Program Co-chair:  Gisli Hjalmtysson, Reykjavik Univ.
Program Co-chair:  Bobby Bhattacharjee, Univ. of Maryland
Publicity Chair:  Tilman Wolf, Univ. of Massachusetts
Webmaster:  Rob Sherwood, Univ. of Maryland

Program Committee
Mostafa Ammar, Georgia Tech       Danny Raz, Technion
Herbert Bos, Leiden Univ.         Sean Rooney, IBM
Bob Braden, ISI                   Timothy Roscoe, Intel
John Byers, Boston Univ.          Antony Rowstron, Microsoft Research
Ken Calvert, Univ. of Kentucky    Dan Rubenstein, Columbia Univ.
Andrew Campbell, Columbia Univ.   Jonathan Smith, UPENN
Hermann De Meer, UCL              Oliver Spachek, AT&T Labs
Jim Griffioen, Univ. of Kentucky  Cormac Sreenan, Univ. College Cork
John Hartman, Univ. of Arizona    James Sterbenz, BBN Technologies
David Hutchinson, Lancaster Univ. Joe Touch, USC/ISI
Scott Karlin, Princeton Univ.     Franco Travostino, Nortel
Pete Keleher, Univ. of Maryland   Christian Tschudin, Univ. of Basel
Aurel Lazar, Columbia Univ.       Jonathan Turner, Washington Univ.
Ian Leslie, Univ. of Cambridge    Raj Yavatkar, Intel
Kobus van der Merwe, AT&T Labs    Ellen Zegura, Georgia Tech
Bernhard Plattner, ETH Zurich     Hui Zhang, Turin Networks & CMU
K. K. Ramakrishnan, AT&T Labs


From owner-ietf-openproxy@mail.imc.org  Thu Oct 17 23:58:00 2002
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05407
	for <opes-archive@ietf.org>; Thu, 17 Oct 2002 23:57:59 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g9I3bQT20932
	for ietf-openproxy-bks; Thu, 17 Oct 2002 20:37:26 -0700 (PDT)
Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g9I3bPW20928
	for <ietf-openproxy@imc.org>; Thu, 17 Oct 2002 20:37:25 -0700 (PDT)
Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215])
 by mtaout06.icomcast.net
 (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug  5 2002))
 with ESMTP id <0H4500C9XREBJS@mtaout06.icomcast.net> for
 ietf-openproxy@imc.org; Thu, 17 Oct 2002 23:37:23 -0400 (EDT)
Date: Thu, 17 Oct 2002 23:37:23 -0400
From: Markus Hofmann <markus@mhof.com>
Subject: Summary of ICAP discussion
To: OPES Group <ietf-openproxy@imc.org>
Message-id: <3DAF81F3.4080302@mhof.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b)
 Gecko/20021016
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7BIT


Hi,

going over the emails that have recently been posted as comments on 
the latest ICAP specification (draft-elson-icap-01.txt), the issues 
raised can be summarized as follows:

(1) The latest ICAP specification as described in Internet Draft
     draft-elson-icap-01.txt is clear and helps in building
     interoperable servers/clients implementations.

(2) Implementation experience shows that ICAP is a relative light
     weight protocol, both in terms of protocol overhead and code
     complexity.

(3) The PREVIEW feature specified in ICAP is considered useful and
     important for real life deployment.

(4) It would be useful to add a standardized mechanism in ICAP that
     allows to convey additional metadata (e.g. client and subscriber
     information), maybe along the lines of the now expired draft on
     "Transmitting Subscriber Identification in iCAP"
     (draft-beck-opes-icap-subid-00.txt). In particular, a mechanism
     for transmitting subscriber information is essential for certain
     services.

(5) Minimum support for security may be provided in ICAP by just
     supporting an additional header similar to WWW-authenticate.

(6) ICAP is specifically designed for HTTP, but attempts have been
     made to encapsulate FTP and even SMTP into ICAP.

(7) The ICAP draft should mention that a single client
     request-response flow could include both reqmod and
     respmod modifications.

(8) It might be helpful to explicitely mention in the draft that ICAP
     clients should be written to check for an ICAP server's response
     while the ICAP client is sending out an encapsulated body.
     Although not directly a protocol issue, this is important to
     speed-up scenarios in which the server can provide a final
     response before receiving the entire message.

Let me further add

(8) the curent ICAP specification doesn't include a mechanism for
     tracing/notification.

(A more detailed discussion of ICAP with respect to the OPES protocol 
requirements can be found in draft-stecher-opes-icap-eval-00.txt)

In the OPES context, does anybody have any more comments on the 
existing ICAP specification. Does anyone have any comments/feelings on 
the above points, or can they be considered a collective view of this 
WG on the existing ICAP specification? In particular:

With respect to point (1), it would be interesting to learn about 
existing implementations that implement the latest ICAP spec and whose 
interoperability has already been tested (well, at least to some extend).

With respect to point (4), would it be helpful to either integrate the 
  mechanim proposed in the expired ID 
draft-beck-opes-icap-subid-00.txt into the ICAP spec, or to publish 
this mechanism in a separate compagnon document? Is this mechanism 
supported in any existing ICAP implementation? If not, how do existing 
ICAP implementations convey subscriber information to services that 
require such information?

With respect to point (5), would it be worthwhile to further explore 
this issue and maybe come up with a proposal for such addition? Or 
would it be better to leave it alone and to refer to Section 7 of the 
ICAP draft, which states the security limitations of the current spec.

With respect to point (6) - Is there a need for a more flexible 
callout protocol that can encapsulate different protocols as well 
(e.g. FTP, SMTP, or maybe even SIP)? Be careful, though - the current 
OPES charter is limited to HTTP (and RTP/RTSP)!!!

Considering the collection of comments, one might state that the 
current draft is pretty stable and describes existing and implemented 
practice, although it has some limitations with respect to the OPES 
architecture and OPES protocl requirements.

Cheers,
   Markus



From owner-ietf-openproxy@mail.imc.org  Fri Oct 18 06:47:34 2002
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20670
	for <opes-archive@ietf.org>; Fri, 18 Oct 2002 06:47:32 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g9IAR3W08952
	for ietf-openproxy-bks; Fri, 18 Oct 2002 03:27:03 -0700 (PDT)
Received: from dns1.tilab.com (dns1.tilab.com [163.162.42.4])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g9IAR2W08948
	for <ietf-openproxy@imc.org>; Fri, 18 Oct 2002 03:27:02 -0700 (PDT)
Received: from iowa.cselt.it (iowa.cselt.it [163.162.4.49])
 by dns1.cselt.it (PMDF V6.0-025 #38895)
 with ESMTP id <0H460096FAAPNE@dns1.cselt.it> for ietf-openproxy@imc.org; Fri,
 18 Oct 2002 12:25:37 +0200 (MEST)
Received: from iowa.cselt.it ([163.162.4.49]) by iowa.cselt.it with Microsoft
 SMTPSVC(5.0.2195.4453); Fri, 18 Oct 2002 12:27:02 +0200
Received: from EXC2K04A.cselt.it ([163.162.161.229])
 by iowa.cselt.it with Microsoft SMTPSVC(5.0.2195.4453); Fri,
 18 Oct 2002 12:27:02 +0200
Received: from EXC2K01B.cselt.it ([163.162.4.97]) by EXC2K04A.cselt.it with
 Microsoft SMTPSVC(5.0.2195.2905); Fri, 18 Oct 2002 12:27:02 +0200
Date: Fri, 18 Oct 2002 12:27:02 +0200
From: Coppola Crescenzo <Crescenzo.Coppola@TILAB.COM>
Subject: OPES Scenarios
To: OPES Group <ietf-openproxy@imc.org>
Message-id: <3549E655A098D2458CE15E0BE3A7D450180A71@EXC2K01B.cselt.it>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Content-type: text/plain; charset=iso-8859-1
Importance: normal
Thread-Topic: Summary of ICAP discussion
Thread-Index: AcJ2WhlQ2vKDUNeXTGWV75sMWAPdxwANedLA
content-class: urn:content-classes:message
X-OriginalArrivalTime: 18 Oct 2002 10:27:02.0657 (UTC)
 FILETIME=[E609DF10:01C27690]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g9IAR2W08949
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit


Hi,

I have a comment on OPES Scenarios. I would add in section 2.1.2 the following point:

- Access functions for the data provider, such as service authentication for access control.

Best regards,
Crescenzo Coppola
System Specialist
Tilab S.p.A.
V. G. Reiss Romoli, 274
10148 Torino - Italy

-----Original Message-----
From: Markus Hofmann [mailto:markus@mhof.com]
Sent: Friday, October 18, 2002 5:37 AM
To: OPES Group
Subject: Summary of ICAP discussion



Hi,

going over the emails that have recently been posted as comments on 
the latest ICAP specification (draft-elson-icap-01.txt), the issues 
raised can be summarized as follows:

(1) The latest ICAP specification as described in Internet Draft
     draft-elson-icap-01.txt is clear and helps in building
     interoperable servers/clients implementations.

(2) Implementation experience shows that ICAP is a relative light
     weight protocol, both in terms of protocol overhead and code
     complexity.

(3) The PREVIEW feature specified in ICAP is considered useful and
     important for real life deployment.

(4) It would be useful to add a standardized mechanism in ICAP that
     allows to convey additional metadata (e.g. client and subscriber
     information), maybe along the lines of the now expired draft on
     "Transmitting Subscriber Identification in iCAP"
     (draft-beck-opes-icap-subid-00.txt). In particular, a mechanism
     for transmitting subscriber information is essential for certain
     services.

(5) Minimum support for security may be provided in ICAP by just
     supporting an additional header similar to WWW-authenticate.

(6) ICAP is specifically designed for HTTP, but attempts have been
     made to encapsulate FTP and even SMTP into ICAP.

(7) The ICAP draft should mention that a single client
     request-response flow could include both reqmod and
     respmod modifications.

(8) It might be helpful to explicitely mention in the draft that ICAP
     clients should be written to check for an ICAP server's response
     while the ICAP client is sending out an encapsulated body.
     Although not directly a protocol issue, this is important to
     speed-up scenarios in which the server can provide a final
     response before receiving the entire message.

Let me further add

(8) the curent ICAP specification doesn't include a mechanism for
     tracing/notification.

(A more detailed discussion of ICAP with respect to the OPES protocol 
requirements can be found in draft-stecher-opes-icap-eval-00.txt)

In the OPES context, does anybody have any more comments on the 
existing ICAP specification. Does anyone have any comments/feelings on 
the above points, or can they be considered a collective view of this 
WG on the existing ICAP specification? In particular:

With respect to point (1), it would be interesting to learn about 
existing implementations that implement the latest ICAP spec and whose 
interoperability has already been tested (well, at least to some extend).

With respect to point (4), would it be helpful to either integrate the 
  mechanim proposed in the expired ID 
draft-beck-opes-icap-subid-00.txt into the ICAP spec, or to publish 
this mechanism in a separate compagnon document? Is this mechanism 
supported in any existing ICAP implementation? If not, how do existing 
ICAP implementations convey subscriber information to services that 
require such information?

With respect to point (5), would it be worthwhile to further explore 
this issue and maybe come up with a proposal for such addition? Or 
would it be better to leave it alone and to refer to Section 7 of the 
ICAP draft, which states the security limitations of the current spec.

With respect to point (6) - Is there a need for a more flexible 
callout protocol that can encapsulate different protocols as well 
(e.g. FTP, SMTP, or maybe even SIP)? Be careful, though - the current 
OPES charter is limited to HTTP (and RTP/RTSP)!!!

Considering the collection of comments, one might state that the 
current draft is pretty stable and describes existing and implemented 
practice, although it has some limitations with respect to the OPES 
architecture and OPES protocl requirements.

Cheers,
   Markus



====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by
replying to MailAdmin@tilab.com. Thank you
====================================================================


From owner-ietf-openproxy@mail.imc.org  Fri Oct 18 08:32:39 2002
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23199
	for <opes-archive@ietf.org>; Fri, 18 Oct 2002 08:32:37 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g9IC3RJ17191
	for ietf-openproxy-bks; Fri, 18 Oct 2002 05:03:27 -0700 (PDT)
Received: from host070.webwasher.com (host070.webwasher.com [195.162.240.70])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g9IC3OW17175
	for <ietf-openproxy@imc.org>; Fri, 18 Oct 2002 05:03:25 -0700 (PDT)
Received: from hermes.webwasher.com [192.168.1.3] id JOECDNGR; 18 Oct 2002 14:16:12 +0100
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Subject: RE: Summary of ICAP discussion
Date: Fri, 18 Oct 2002 14:01:09 +0200
Message-ID: <72992B39BBD9294BB636A960E89AE02E50BFE8@hermes.webwasher.com>
Thread-Topic: Summary of ICAP discussion
Thread-Index: AcJ2WJEwE2UuiRPoQOCmDMQhrHh1vgAQS+YQ
From: "Martin Stecher" <martin.stecher@webwasher.com>
To: "OPES Group" <ietf-openproxy@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g9IC3QW17188
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit


Hi,

re (3): This is true but I like to add again that having the ability to have even more decision points would be even more useful, i.e. ICAP server could request a second (or third) preview if the data in the first preview was not sufficient but it still doubts that it needs the complete data.

re (4): Most implementations support the X-Client-IP header. I don't know any implementation supporting X-Subscriber-ID.
There are also other headers in use like X-Authenticated-User and X-Authenticated-Group.
We should collect them and put them in a compagnon document. It makes no sense to put them in the ICAP specs directly because they are all X-Headers which would probably not be appropriate. But changing the header names would create a new protocol version which all existing implementations are not longer compatible to.

re (5): Should be worthwile to explore on this but I don't see this to be an urgent task. Today ICAP solutions are often deployed in a way that makes authentication obsolete (special interface card and private ICAP network).

Reasons to update the existing draft are (7) and (8) and maybe another point I found recently:
(10) The specs could be more specific about the list of allowed response codes other than given in the specs today rather than just refering to the HTTP protocol semantics.

I think these reasons (7), (8) and (10) are not strong enough to motiviate for a new draft now. Point (1) is the most important one.

Therefore I vote for this procedure:

1. Name draft-elson-icap-01.txt THE ICAP/1.0 protocol specification and let it become an RFC as is.

2. Work on a compagnon document that considers (4) and maybe also (5),(7),(8),(10)

3. Start with the work on a new protocol that considers all OPES requirements and my comment to (3) above and is more flexible regarding other application protocols (6) and also includes (9). Whether that new protocol is then called ICAP/1.x, ICAP/2.0 or totally different is not important right now.


Martin


> -----Original Message-----
> From: Markus Hofmann [mailto:markus@mhof.com]
> Sent: Friday, October 18, 2002 5:37 AM
> To: OPES Group
> Subject: Summary of ICAP discussion
> 
> 
> 
> Hi,
> 
> going over the emails that have recently been posted as comments on 
> the latest ICAP specification (draft-elson-icap-01.txt), the issues 
> raised can be summarized as follows:
> 
> (1) The latest ICAP specification as described in Internet Draft
>      draft-elson-icap-01.txt is clear and helps in building
>      interoperable servers/clients implementations.
> 
> (2) Implementation experience shows that ICAP is a relative light
>      weight protocol, both in terms of protocol overhead and code
>      complexity.
> 
> (3) The PREVIEW feature specified in ICAP is considered useful and
>      important for real life deployment.
> 
> (4) It would be useful to add a standardized mechanism in ICAP that
>      allows to convey additional metadata (e.g. client and subscriber
>      information), maybe along the lines of the now expired draft on
>      "Transmitting Subscriber Identification in iCAP"
>      (draft-beck-opes-icap-subid-00.txt). In particular, a mechanism
>      for transmitting subscriber information is essential for certain
>      services.
> 
> (5) Minimum support for security may be provided in ICAP by just
>      supporting an additional header similar to WWW-authenticate.
> 
> (6) ICAP is specifically designed for HTTP, but attempts have been
>      made to encapsulate FTP and even SMTP into ICAP.
> 
> (7) The ICAP draft should mention that a single client
>      request-response flow could include both reqmod and
>      respmod modifications.
> 
> (8) It might be helpful to explicitely mention in the draft that ICAP
>      clients should be written to check for an ICAP server's response
>      while the ICAP client is sending out an encapsulated body.
>      Although not directly a protocol issue, this is important to
>      speed-up scenarios in which the server can provide a final
>      response before receiving the entire message.
> 
> Let me further add
> 
> (8) the curent ICAP specification doesn't include a mechanism for
>      tracing/notification.
> 
> (A more detailed discussion of ICAP with respect to the OPES protocol 
> requirements can be found in draft-stecher-opes-icap-eval-00.txt)
> 
> In the OPES context, does anybody have any more comments on the 
> existing ICAP specification. Does anyone have any 
> comments/feelings on 
> the above points, or can they be considered a collective view of this 
> WG on the existing ICAP specification? In particular:
> 
> With respect to point (1), it would be interesting to learn about 
> existing implementations that implement the latest ICAP spec 
> and whose 
> interoperability has already been tested (well, at least to 
> some extend).
> 
> With respect to point (4), would it be helpful to either 
> integrate the 
>   mechanim proposed in the expired ID 
> draft-beck-opes-icap-subid-00.txt into the ICAP spec, or to publish 
> this mechanism in a separate compagnon document? Is this mechanism 
> supported in any existing ICAP implementation? If not, how do 
> existing 
> ICAP implementations convey subscriber information to services that 
> require such information?
> 
> With respect to point (5), would it be worthwhile to further explore 
> this issue and maybe come up with a proposal for such addition? Or 
> would it be better to leave it alone and to refer to Section 7 of the 
> ICAP draft, which states the security limitations of the current spec.
> 
> With respect to point (6) - Is there a need for a more flexible 
> callout protocol that can encapsulate different protocols as well 
> (e.g. FTP, SMTP, or maybe even SIP)? Be careful, though - the current 
> OPES charter is limited to HTTP (and RTP/RTSP)!!!
> 
> Considering the collection of comments, one might state that the 
> current draft is pretty stable and describes existing and implemented 
> practice, although it has some limitations with respect to the OPES 
> architecture and OPES protocl requirements.
> 
> Cheers,
>    Markus
> 
> 


From owner-ietf-openproxy@mail.imc.org  Fri Oct 18 17:29:45 2002
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10675
	for <opes-archive@ietf.org>; Fri, 18 Oct 2002 17:29:44 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g9IL0Dl15813
	for ietf-openproxy-bks; Fri, 18 Oct 2002 14:00:13 -0700 (PDT)
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g9IL0BW15809
	for <ietf-openproxy@imc.org>; Fri, 18 Oct 2002 14:00:11 -0700 (PDT)
Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10])
	by crufty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g9IL01LI027642
	for <ietf-openproxy@imc.org>; Fri, 18 Oct 2002 17:00:03 -0400 (EDT)
Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8])
	by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g9IKxqI70696
	for <ietf-openproxy@imc.org>; Fri, 18 Oct 2002 16:59:55 -0400 (EDT)
Received: from mhof.com (navajo [135.180.160.24])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id QAA16152
	for <ietf-openproxy@imc.org>; Fri, 18 Oct 2002 16:59:51 -0400 (EDT)
Message-ID: <3DB07651.8070206@mhof.com>
Date: Fri, 18 Oct 2002 17:00:01 -0400
From: Markus Hofmann <markus@mhof.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: OPES Group <ietf-openproxy@imc.org>
Subject: Re: Summary of ICAP discussion
References: <72992B39BBD9294BB636A960E89AE02E50BFE8@hermes.webwasher.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


Martin,

 > re (3): This is true but I like to add again that having the
 > ability to have even more decision points would be even more
 > useful, i.e. ICAP server could request a second (or third) preview
 > if the data in the first preview was not sufficient but it still
 > doubts that it needs the complete data.

As Jeff mentioned in an earlier email, isn't an ICAP server allowed by 
the ICAP internet draft to reply to an ICAP client before the ICAP 
server has received the entire encapsulated body? As such, rather than 
requesting a second preview, the ICAP server can request to send the 
entire message, and than simply reply once it has received enough data 
to make an informed decision. Might even be the prefered way, since it 
might not be the case very often that the second and thrd preview ize 
will be static and know a-priori? Or do you have a specific 
scenario/application in mind?

 > re (4): Most implementations support the X-Client-IP header. I
 > don't know any implementation supporting X-Subscriber-ID. There are
 > also other headers in use like X-Authenticated-User and
 > X-Authenticated-Group. We should collect them and put them in a
 > compagnon document. It makes no sense to put them in the ICAP specs
 > directly because they are all X-Headers which would probably not be
 > appropriate. But changing the header names would create a new
 > protocol version which all existing implementations are not longer
 > compatible to.

A compagnon document summarizing the common usage of such headers 
would be very helpful and, IMHO, important.

 > Therefore I vote for this procedure:
 >
 > 1. Name draft-elson-icap-01.txt THE ICAP/1.0 protocol specification
 > and let it become an RFC as is.

This would be an individual RFC, and not the result of the WG.

 > 2. Work on a compagnon document that considers (4) and maybe also
 > (5),(7),(8),(10)

I would *not* merge 5,7,8,10 in there, but rather have a compagnon 
document only on 4 (and related, commonly used (X-)headers).

 > 3. Start with the work on a new protocol that considers all OPES
 > requirements and my comment to (3) above and is more flexible
 > regarding other application protocols (6) and also includes (9).
 > Whether that new protocol is then called ICAP/1.x, ICAP/2.0 or
 > totally different is not important right now.

Sounds reasonable.

Note however, that the decision on how to proceed with the ICAP draft, 
is with our ADs and the IESG, and not a WG issue. The WG is just 
expected to "... SUPPORT development of an analysis that explains the 
limitations of ICAP...".

Thanks,
-Markus



From owner-ietf-openproxy@mail.imc.org  Fri Oct 18 18:14:22 2002
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11231
	for <opes-archive@ietf.org>; Fri, 18 Oct 2002 18:14:21 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g9ILoFo18776
	for ietf-openproxy-bks; Fri, 18 Oct 2002 14:50:15 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g9ILoEW18771
	for <ietf-openproxy@imc.org>; Fri, 18 Oct 2002 14:50:14 -0700 (PDT)
Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10])
	by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g9ILo8hN044945;
	Fri, 18 Oct 2002 17:50:08 -0400 (EDT)
Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8])
	by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g9ILo2I74331;
	Fri, 18 Oct 2002 17:50:02 -0400 (EDT)
Received: from bell-labs.com ([135.180.160.178])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id RAA17674;
	Fri, 18 Oct 2002 17:50:01 -0400 (EDT)
Message-ID: <3DB081E8.2030402@bell-labs.com>
Date: Fri, 18 Oct 2002 17:49:28 -0400
From: Andre Beck <abeck@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-US,de,es
MIME-Version: 1.0
To: Martin Stecher <martin.stecher@webwasher.com>
CC: OPES Group <ietf-openproxy@imc.org>
Subject: Re: Summary of ICAP discussion
References: <72992B39BBD9294BB636A960E89AE02E50BFE8@hermes.webwasher.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


Martin Stecher wrote:
 > re (4): Most implementations support the X-Client-IP header. I don't
 > know any implementation supporting X-Subscriber-ID.

The Bell Labs ISE (ICAP server) as well as our ICAP client library 
support both headers. Applications incorporating our ICAP client library 
can set the X-Client-IP and X-Subscriber-ID headers when sending ICAP 
requests and service modules for the ISE have access to the values of 
these headers (if present).

-Andre




From owner-ietf-openproxy@mail.imc.org  Fri Oct 18 19:01:55 2002
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11939
	for <opes-archive@ietf.org>; Fri, 18 Oct 2002 19:01:54 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g9IMad222219
	for ietf-openproxy-bks; Fri, 18 Oct 2002 15:36:39 -0700 (PDT)
Received: from host070.webwasher.com (host070.webwasher.com [195.162.240.70])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g9IMaaW22214
	for <ietf-openproxy@imc.org>; Fri, 18 Oct 2002 15:36:37 -0700 (PDT)
Received: from hermes.webwasher.com [192.168.1.3] id ZJJQ4OBZ; 19 Oct 2002 00:49:30 +0100
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Subject: AW: Summary of ICAP discussion
Date: Sat, 19 Oct 2002 00:34:24 +0200
Message-ID: <72992B39BBD9294BB636A960E89AE02E50BFEB@hermes.webwasher.com>
Thread-Topic: Summary of ICAP discussion
Thread-Index: AcJ26t1zhthgQemLTfaAVQ/2BJNvGgACfw/w
From: "Martin Stecher" <martin.stecher@webwasher.com>
To: "OPES Group" <ietf-openproxy@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g9IMacW22215
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit


Hi Markus,

> As Jeff mentioned in an earlier email, isn't an ICAP server 
> allowed by 
> the ICAP internet draft to reply to an ICAP client before the ICAP 
> server has received the entire encapsulated body? As such, 
> rather than 
> requesting a second preview, the ICAP server can request to send the 
> entire message, and than simply reply once it has received 
> enough data 
> to make an informed decision. Might even be the prefered way, 
> since it 
> might not be the case very often that the second and thrd preview ize 
> will be static and know a-priori? Or do you have a specific 
> scenario/application in mind?

That's right. It is very important that the ICAP server can start to send back data and that the client allows this and actively reads the data, otherwise its window size can go down to zero which can freeze the complete communication on that connection.
The procedure you subscribe is how it is done today if the ICAP server cannot answer with 204 after the preview.

But what I mean is an extension to that procedure.

Imagine that an ICAP server likes to be very sure that a claimed file type is really that file type. Let's say the ICAP server does not care about Quicktime movies and would like to answer with 204 for all those movies. But it has to be sure that the file is really a Quicktime movie.
The prefered preview size could be eight bytes and this will usually be enough to check the start of the file which typically shows the bytes 'moov' as the bytes 4-7 of the file. So usually right after the preview the ICAP server can answer with 204.
But in principle a Quicktime movie file could start with another atom and could have the 'moov' atom somewhere else. So the ICAP server gets eight bytes that could be a Quicktime movie but it is not sure.
Today the ICAP server will respond with 100 Continue and will now get the other 5 MB of the file transfered. Even if after another 100 bytes the ICAP server finds the moov atom and is not longer interested in the file it needs to receive and play back the complete file, wasting a lot of bandwidth.

So what I suggest is that a next protocol version offers the ability to return an additional value with the 100 Continue response specifying that the ICAP server likes to see an extended preview, maybe another 1KB and will then decide again whether to get the complete rest or to stop at that decision point with 204.

Martin


From owner-ietf-openproxy@mail.imc.org  Fri Oct 18 19:12:01 2002
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12097
	for <opes-archive@ietf.org>; Fri, 18 Oct 2002 19:12:00 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g9IMkpY22430
	for ietf-openproxy-bks; Fri, 18 Oct 2002 15:46:51 -0700 (PDT)
Received: from host070.webwasher.com (host070.webwasher.com [195.162.240.70])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g9IMknW22425
	for <ietf-openproxy@imc.org>; Fri, 18 Oct 2002 15:46:49 -0700 (PDT)
Received: from hermes.webwasher.com [192.168.1.3] id T9TYS5AU; 19 Oct 2002 00:59:43 +0100
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Subject: AW: Summary of ICAP discussion
Date: Sat, 19 Oct 2002 00:44:37 +0200
Message-ID: <72992B39BBD9294BB636A960E89AE02E50BFEC@hermes.webwasher.com>
Thread-Topic: Summary of ICAP discussion
Thread-Index: AcJ26t1zhthgQemLTfaAVQ/2BJNvGgADBrWA
From: "Martin Stecher" <martin.stecher@webwasher.com>
To: "OPES Group" <ietf-openproxy@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g9IMkoW22427
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit


Hi again,

>  > re (4): Most implementations support the X-Client-IP header. I
>  > don't know any implementation supporting X-Subscriber-ID. There are
>  > also other headers in use like X-Authenticated-User and
>  > X-Authenticated-Group. We should collect them and put them in a
>  > compagnon document. It makes no sense to put them in the ICAP specs
>  > directly because they are all X-Headers which would probably not be
>  > appropriate. But changing the header names would create a new
>  > protocol version which all existing implementations are not longer
>  > compatible to.
> 
> A compagnon document summarizing the common usage of such headers 
> would be very helpful and, IMHO, important.

I fully agree. Anybody who likes to help to create that document?

> 
>  > Therefore I vote for this procedure:
>  >
>  > 1. Name draft-elson-icap-01.txt THE ICAP/1.0 protocol specification
>  > and let it become an RFC as is.
> 
> This would be an individual RFC, and not the result of the WG.

Yes, of course; it has been published nearly a year ago.
Why do you use "would"?
Do you suggest to create a WG version of that draft? Maybe with some additions that consider points (4) to (10)?

> 
>  > 2. Work on a compagnon document that considers (4) and maybe also
>  > (5),(7),(8),(10)
> 
> I would *not* merge 5,7,8,10 in there, but rather have a compagnon 
> document only on 4 (and related, commonly used (X-)headers).

Agreed.

> 
>  > 3. Start with the work on a new protocol that considers all OPES
>  > requirements and my comment to (3) above and is more flexible
>  > regarding other application protocols (6) and also includes (9).
>  > Whether that new protocol is then called ICAP/1.x, ICAP/2.0 or
>  > totally different is not important right now.
> 
> Sounds reasonable.
> 
> Note however, that the decision on how to proceed with the 
> ICAP draft, 
> is with our ADs and the IESG, and not a WG issue. The WG is just 
> expected to "... SUPPORT development of an analysis that explains the 
> limitations of ICAP...".

And I hope that this WG task can finally be finished now so that the ADs and IESG can continue.

Regards
Martin


From owner-ietf-openproxy@mail.imc.org  Fri Oct 18 21:15:55 2002
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13836
	for <opes-archive@ietf.org>; Fri, 18 Oct 2002 21:15:54 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g9J0pCA25936
	for ietf-openproxy-bks; Fri, 18 Oct 2002 17:51:12 -0700 (PDT)
Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g9J0pBW25932
	for <ietf-openproxy@imc.org>; Fri, 18 Oct 2002 17:51:11 -0700 (PDT)
Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215])
 by mtaout05.icomcast.net
 (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug  5 2002))
 with ESMTP id <0H4700313ED92I@mtaout05.icomcast.net> for
 ietf-openproxy@imc.org; Fri, 18 Oct 2002 20:51:09 -0400 (EDT)
Date: Fri, 18 Oct 2002 20:51:09 -0400
From: Markus Hofmann <markus@mhof.com>
Subject: Re: AW: Summary of ICAP discussion
In-reply-to: <72992B39BBD9294BB636A960E89AE02E50BFEC@hermes.webwasher.com>
To: OPES Group <ietf-openproxy@imc.org>
Message-id: <3DB0AC7D.5030908@mhof.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b)
 Gecko/20021016
References: <72992B39BBD9294BB636A960E89AE02E50BFEC@hermes.webwasher.com>
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7BIT


Martin Stecher wrote:

> >A compagnon document summarizing the common usage of such headers
> >would be very helpful and, IMHO, important.
>
> I fully agree. Anybody who likes to help to create that document?

That shouldn't be a big effort. If we use the expired draft on 
"Transmitting Subscriber Identification in iCAP" as a starting point, 
the other few commonly implemented X-headers can easily be added. I'll 
get in touch with you to wrap this up and close on it.

> Yes, of course; it has been published nearly a year ago.
> Why do you use "would"?

Because it is not (yet) an RFC, therefore the subjunctive.

> Do you suggest to create a WG version of that draft? Maybe with some 
> additions that consider points (4) to (10)?

No!!!

-Markus



From owner-ietf-openproxy@mail.imc.org  Fri Oct 18 21:17:24 2002
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13891
	for <opes-archive@ietf.org>; Fri, 18 Oct 2002 21:17:23 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g9J0vwh26219
	for ietf-openproxy-bks; Fri, 18 Oct 2002 17:57:58 -0700 (PDT)
Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g9J0vvW26213
	for <ietf-openproxy@imc.org>; Fri, 18 Oct 2002 17:57:57 -0700 (PDT)
Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215])
 by mtaout04.icomcast.net
 (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug  5 2002))
 with ESMTP id <0H4700GJNEOJOK@mtaout04.icomcast.net> for
 ietf-openproxy@imc.org; Fri, 18 Oct 2002 20:57:55 -0400 (EDT)
Date: Fri, 18 Oct 2002 20:57:55 -0400
From: Markus Hofmann <markus@mhof.com>
Subject: Re: AW: Summary of ICAP discussion
In-reply-to: <72992B39BBD9294BB636A960E89AE02E50BFEB@hermes.webwasher.com>
To: OPES Group <ietf-openproxy@imc.org>
Message-id: <3DB0AE13.5080609@mhof.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b)
 Gecko/20021016
References: <72992B39BBD9294BB636A960E89AE02E50BFEB@hermes.webwasher.com>
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7BIT


Martin,

I'm completely with you, thanks for the clarification. What you 
describe is covered - in a more general case - in Section 3.1 of the 
OPES protocol requirements draft.

Thanks,
   Markus

Martin Stecher wrote:

> Hi Markus,
>
>
> >As Jeff mentioned in an earlier email, isn't an ICAP server
> >allowed by
> >the ICAP internet draft to reply to an ICAP client before the ICAP
> >server has received the entire encapsulated body? As such,
> >rather than
> >requesting a second preview, the ICAP server can request to send the
> >entire message, and than simply reply once it has received
> >enough data
> >to make an informed decision. Might even be the prefered way,
> >since it
> >might not be the case very often that the second and thrd preview ize
> >will be static and know a-priori? Or do you have a specific
> >scenario/application in mind?
>
>
> That's right. It is very important that the ICAP server can start to 
> send back data and that the client allows this and actively reads 
> the data, otherwise its window size can go down to zero which can 
> freeze the complete communication on that connection.
> The procedure you subscribe is how it is done today if the ICAP 
> server cannot answer with 204 after the preview.
>
> But what I mean is an extension to that procedure.
>
> Imagine that an ICAP server likes to be very sure that a claimed 
> file type is really that file type. Let's say the ICAP server does 
> not care about Quicktime movies and would like to answer with 204 
> for all those movies. But it has to be sure that the file is really 
> a Quicktime movie.
> The prefered preview size could be eight bytes and this will usually 
> be enough to check the start of the file which typically shows the 
> bytes 'moov' as the bytes 4-7 of the file. So usually right after 
> the preview the ICAP server can answer with 204.
> But in principle a Quicktime movie file could start with another 
> atom and could have the 'moov' atom somewhere else. So the ICAP 
> server gets eight bytes that could be a Quicktime movie but it is 
> not sure.
> Today the ICAP server will respond with 100 Continue and will now 
> get the other 5 MB of the file transfered. Even if after another 100 
> bytes the ICAP server finds the moov atom and is not longer 
> interested in the file it needs to receive and play back the 
> complete file, wasting a lot of bandwidth.
>
> So what I suggest is that a next protocol version offers the ability 
> to return an additional value with the 100 Continue response 
> specifying that the ICAP server likes to see an extended preview, 
> maybe another 1KB and will then decide again whether to get the 
> complete rest or to stop at that decision point with 204.
>
> Martin
>



From owner-ietf-openproxy@mail.imc.org  Sun Oct 20 09:52:51 2002
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27615
	for <opes-archive@ietf.org>; Sun, 20 Oct 2002 09:52:48 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g9KDBQd09527
	for ietf-openproxy-bks; Sun, 20 Oct 2002 06:11:26 -0700 (PDT)
Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g9KDBOW09521
	for <ietf-openproxy@imc.org>; Sun, 20 Oct 2002 06:11:25 -0700 (PDT)
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9KDB2K18284;
	Sun, 20 Oct 2002 09:11:02 -0400 (EDT)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <TLKCGQCS>; Sun, 20 Oct 2002 09:11:03 -0400
Message-ID: <87609AFB433BD5118D5E0002A52CD75403E3FB60@zcard0k6.ca.nortel.com>
From: "Abbie Barbir" <abbieb@nortelnetworks.com>
To: internet-drafts@ietf.org
Cc: ietf-openproxy@imc.org, "Abbie Barbir" <abbieb@nortelnetworks.com>,
        Markus Hofmann <markus@mhof.com>,
        Marshall Rose <mrose@dbc.mtview.ca.us>
Subject: Publish Draft: draft-ietf-opes-threats-00
Date: Sun, 20 Oct 2002 09:11:02 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C2783A.21B9889E"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C2783A.21B9889E
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2783A.21B9889E"


------_=_NextPart_001_01C2783A.21B9889E
Content-Type: text/plain

Please publish the attached as an Internet Draft 
draft-ietf-opes-threats-00
thanks 
abbie  <<draft-ietf-opes-threats-00.txt>> 


------_=_NextPart_001_01C2783A.21B9889E
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>Publish Draft: draft-ietf-opes-threats-00</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Times New Roman">Please publish the attached =
as an Internet Draft</FONT><FONT FACE=3D"Times New Roman"> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">draft-ietf-opes-threats-00</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Times New Roman">thanks</FONT><FONT =
FACE=3D"Times New Roman"> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Times New Roman">abbie</FONT><FONT =
FACE=3D"Times New Roman"><FONT FACE=3D"Arial" SIZE=3D2 =
COLOR=3D"#000000">  &lt;&lt;draft-ietf-opes-threats-00.txt&gt;&gt; =
</FONT></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2783A.21B9889E--

------_=_NextPart_000_01C2783A.21B9889E
Content-Type: text/plain;
	name="draft-ietf-opes-threats-00.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-opes-threats-00.txt"
Content-Transfer-Encoding: quoted-printable



Network Working Group                                         A. Barbir
Internet-Draft                                           Nortel =
Networks
Expires: April 20, 2003                                       O. =
Batuner
                                                  Independent =
consultant
                                                                 T. =
Chan
                                                             B. =
Srinivas
                                                                   =
Nokia
                                                                H. =
Orman
                                               Purple Streak =
Development
                                                        October 20, =
2002


      Security Threats and Risks for Open Pluggable Edge Services
                       draft-ietf-opes-threats-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six =
months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 20, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   The document investigates the security threats associated with OPES.
   The effects of security threats on the underlying architecture are
   discussed.  The document does not specify or recommend any =
solutions.
   Proposed solutions are viewed as illustrations of the nature of
   threats.



Barbir , et al.          Expires April 20, 2003                 [Page =
1]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


Table of Contents

   1.     Introduction . . . . . . . . . . . . . . . . . . . . . . .   =
3
   2.     OPES Data Flow Threats . . . . . . . . . . . . . . . . . .   =
5
   2.1    OPES Flow Network Level Threats  . . . . . . . . . . . . .   =
6
   2.1.1  OPES device spoofing . . . . . . . . . . . . . . . . . . .   =
6
   2.1.2  Remote callout server spoofing . . . . . . . . . . . . . .   =
7
   2.1.3  Session Hijacking  . . . . . . . . . . . . . . . . . . . .   =
7
   2.1.4  Threats to data confidentiality (eavesdropping)  . . . . .   =
7
   2.1.5  Denial-of-Service (DoS)  . . . . . . . . . . . . . . . . .   =
7
   2.1.6  Threats to network robustness  . . . . . . . . . . . . . .   =
8
   2.2    OPES Flow Application Level Threats  . . . . . . . . . . .   =
8
   2.2.1  Unauthorized OPES entities . . . . . . . . . . . . . . . .   =
8
   2.2.2  Unauthorized actions of legitimate OPES entities . . . . .   =
8
   2.2.3  Unwanted content transformations . . . . . . . . . . . . .   =
9
   2.2.4  Corrupted content  . . . . . . . . . . . . . . . . . . . .   =
9
   2.2.5  Threats to message structure integrity . . . . . . . . . .   =
9
   2.2.6  Granularity of protection  . . . . . . . . . . . . . . . .   =
9
   2.2.7  Risks of hop-by-hop protections  . . . . . . . . . . . . .  =
10
   2.2.8  Threats to integrity of complex data . . . . . . . . . . .  =
10
   2.2.9  Denial of Service (DoS)  . . . . . . . . . . . . . . . . .  =
11
   2.2.10 Tracing and notification information . . . . . . . . . . .  =
11
   3.     Threats to out-of-band data  . . . . . . . . . . . . . . .  =
12
   3.1    Threats that endanger OPES data flow . . . . . . . . . . .  =
12
   3.2    Inaccurate Accounting Information  . . . . . . . . . . . .  =
12
   3.3    OPES service request repudiation . . . . . . . . . . . . .  =
13
   3.4    Exposure of private information  . . . . . . . . . . . . .  =
13
   3.5    Inconsistent privacy policy  . . . . . . . . . . . . . . .  =
13
   3.6    Exposure of privacy preferences  . . . . . . . . . . . . .  =
13
   3.7    Exposure of security settings  . . . . . . . . . . . . . .  =
13
   3.8    Improper enforcement of privacy and security policy  . . .  =
14
   4.     Problems related to the cryptographic data protection  . .  =
15
   5.     Security Considerations  . . . . . . . . . . . . . . . . .  =
16
          References . . . . . . . . . . . . . . . . . . . . . . . .  =
17
          Authors' Addresses . . . . . . . . . . . . . . . . . . . .  =
17
   A.     Acknowledgements . . . . . . . . . . . . . . . . . . . . .  =
19
          Full Copyright Statement . . . . . . . . . . . . . . . . .  =
20














Barbir , et al.          Expires April 20, 2003                 [Page =
2]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


1. Introduction

   The Open Pluggable Edge Services (OPES) [1]  architecture enables
   cooperative application services (OPES services) between a data
   provider, a data consumer, and zero or more OPES processors.  The
   application services under consideration analyze and possibly
   transform application-level messages exchanged between the data
   provider and the data consumer.  The OPES processor can distribute
   the responsibility of service execution by communicating and
   collaborating with one or more remote callout servers.  The details
   of the OPES architecture can be found in  [1].

   Security threats with respect to OPES can be viewed from different
   angles.  There are security risks that affect content consumer
   applications, and those that affect the data provider applications.
   These threats affect the quality and integrity of data that the
   applications either produce or consume.  On the other hand, the
   security risks can also be categorized into trust within the system
   (i.e.  OPES service providers) and protection of the system from
   threats imposed by outsiders such as hackers and attackers.  =
Insiders
   are those parties that are part of the OPES system.  Outsiders are
   those entities that are not participating in the OPES system.

   It is up to OPES service providers to verify the trust relationship
   between them, whereby intentional false information is tracked.
   Insiders can intentionally or unintentionally inflect harm and =
damage
   on the data consumer and data provider applications.  This can be
   through bad system configuration, execution of bad software or, if
   their networks are compromised, by hackers.

   Depending on the deployment scenario, the trust within the OPES
   system is based on a transitive trust between the data provider
   application, the OPES entities and the data consumer application.
   Threats to OPES entities can be at the OPES flow level and/or at the
   network level.

   In considering threats to the OPES system, the document will follow =
a
   threat analysis model that identifies the threats from the
   prospective of how it will affect the data consumer and the data
   provider applications.

   The main goal of this document is threat discovery and analysis.  =
The
   document does not specify or recommend any solutions.  Proposed
   solutions are viewed as illustrations of the nature of threats.

   It is important to mention that the OPES architecture has many
   similarities with other so called overlay networks, specifically web
   caches and content delivery networks (CDN) (see [2] , [4] ).  This



Barbir , et al.          Expires April 20, 2003                 [Page =
3]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


   document focuses on threats that are introduced by the existence of
   the OPES processor and callout servers.  Security threats specific =
to
   content services that do not use the OPES architecture are =
considered
   out-of-scope of this document.  However, this document can be used =
as
   input when considering security implications for web caches and =
CDNs.

   The document is organized as follows: Section 2 discusses threats to
   OPES data flow on network and application level, section 3 discusses
   threats to other parts of the system and section 4 discusses =
problems
   related to the cryptographic data protection paying special =
attention
   to the hop-by-hop versus end-to-end protection.








































Barbir , et al.          Expires April 20, 2003                 [Page =
4]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


2. OPES Data Flow Threats

   Threats to OPES data flow can affect the data consumer and data
   provider applications.  At the OPES flow level, threats can occur at
   Policy Enforcement Points and Policy Decision Points [3]  and along
   the OPES flow path where networks elements are used to process the
   data.

   A serious problem is posed by the very fact that the OPES
   architecture is based on widely adopted protocols (HTTP is used as =
an
   example).  The architecture document specifically requires that "the
   presence of an OPES processor in the data request/response flow =
SHALL
   NOT interfere with the operations of non-OPES aware clients and
   servers".  This greatly facilitates OPES deployment but on the other
   hand a vast majority of clients (browsers) will not be able to
   exploit any safeguards added as a base protocol extensions.

   In reality active investigative actions are not feasible for the
   regular end user (Where this content comes from? Can I get it =
another
   way? What is the difference? Is it legitimate?).  Even if there are
   facilities and technical expertise present to pursue these questions
   such thorough examination of each result is prohibitively expensive
   in terms of time and effort.  OPES-aware content providers may try =
to
   protect themselves by adding verification scripts and special page
   structures.  OPES-aware end users may use special tools.  In all
   other cases (non-OPES aware clients and servers) protection will =
rely
   on monitoring services and investigation of occasionally discovered
   accidents.

   OPES system poses a special danger as a possible base for classical
   man-in-the-middle attack.  One of the reasons why such attacks are
   relatively rare is difficulty in finding an appropriate base: a
   combination of a traffic interception point controlling consistent
   flow of data and an application codebase with sufficient performance
   to analyze and possible modify all passing data.  OPES processor
   perfectly meets this definition.  This calls for a special attention
   to protection measures at all levels of the system.

   Any break into an OPES processor or remote callout server can have a
   ripple effect on the integrity of the affected OPES services across
   all service providers that use the service.  To mitigate this threat
   appropriate security procedures and tools (e.g., a firewall) should
   be applied.

   Specific threats can be at the network level and at OPES data flow
   level.





Barbir , et al.          Expires April 20, 2003                 [Page =
5]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


2.1 OPES Flow Network Level Threats

   OPES processor and callout servers are susceptible to network level
   attacks from outsiders or from the networks of other OPES service
   providers (i.e.  if the network of a contracted OPES service is
   compromised).

   OPES architecture is based on common application protocols that do
   not provide strong guarantees of privacy, authentication, or
   integrity.  The IAB considerations [4]  require that the IP address
   of an OPES processor be accessible to data consumer applications at
   the IP level.  This exposes the OPES processor including remote
   callout servers to network level attacks.  Use of TCP/IP as network
   level protocol makes OPES processors subject to many known attacks,
   like IP spoofing and session stealing.

   The OPES system is also susceptible to a number of security threats
   that are commonly associated with network infrastructure.  These
   threats include snooping, denial of service, sabotage, vandalism,
   industrial espionage, theft of service and inadequate system
   configuration that leaves unneeded ports and services open to the
   public.

   There are best practice solutions to mitigate network level threats.
   It is recommended that the security of the OPES entities at the
   network level be enhanced using known techniques and methods that
   minimize the risks of IP spoofing, snooping, denial of service and
   session stealing.

   In the following subsections we take a more detailed look at these
   threats and potential resulting harm.

2.1.1 OPES device spoofing

   A malicious node could send false information about itself
   masquerading as an OPES device.  Alternatively, despite the presence
   of a genuine OPES device which has been authenticated, the actual
   data transformation could be performed in a malicious colocated
   callout server which is resident in the same administrative domain =
as
   the OPES device.  Furthermore, the malicious node could force the
   consumer or producer to use the services of a malicious OPES
   intermediary, which might render undesired or very expensive
   transformation services.

   As a consequence, the malicious device would be able to eavesdrop on
   all traffic between the end-systems.  In addition, unexpected and
   undesirable data transformation by the malicious intermediary or
   callout server would result.  Finally, the malicious entity, that



Barbir , et al.          Expires April 20, 2003                 [Page =
6]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


   successfully spoofs an OPES intermediary (or callout server), may
   refuse to forward the legitimate traffic to the content consumers,
   resulting in a Denial-of-Service attack.

2.1.2 Remote callout server spoofing

   Similar to the threat described in 2.1.1, a malicious node could
   masquerade as a remote callout server.  Despite the presence of an
   authenticated OPES device, the malicious data transformation could =
be
   performed in a remote callout server.

   The effect of having such a malicious remote callout server is very
   similar to those produced by having a malicious OPES device or
   colocated callout server (see 2.1.1).

2.1.3 Session Hijacking

   If a TCP/IP session is hijacked by an attacker, it would be possible
   for the hijacker to compromise the integrity of content on an OPES
   processor.

2.1.4 Threats to data confidentiality (eavesdropping)

   An eavesdropper is typically capable of snooping on fields within
   messages in transit.  Using various eavesdropping techniques, he may
   be able to garner various kinds of information including topology/
   location/IP addresses etc.  that may not be desirable to divulge.  =
He
   also may be able to eavesdrop on the content messages being =
delivered
   to the consumer.  Furthermore, to ensure secure data traversal from
   the provider to the consumer, authentication information must be
   exchanged between the provider and the consumer.  When such security
   related information has to traverse through an OPES system, it is
   also subject to the threat of being eavesdropped on by the malicious
   entity.

2.1.5 Denial-of-Service (DoS)

   The intermediary or the callout server can be overloaded by spurious
   service requests issued by a malicious node, which denies the legal
   data traffic the necessary resources to render service.  The
   resources include CPU cycles, memory, network interfaces, etc.  A
   Denial-of-Service attack can be selective, generic or random in =
terms
   of which communication streams are affected.

   Distributed DoS is also possible when an attacker successfully
   directs multiple nodes over the network to initiate spurious service
   requests to an OPES intermediary (or call-out server) =
simultaneously.




Barbir , et al.          Expires April 20, 2003                 [Page =
7]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


2.1.6 Threats to network robustness

   if OPES implementation does violate end-to-end addressing =
principles,
   it could endangers the Internet infrastructure by complicating
   routing and connection management.  If it does not use flow-control
   principles for managing connections, or if it interferes with =
end-to-
   end flow control of connections that it did not originate, then it
   could causing Internet congestion.

   An implementation that violates IAB requirement of explicit IP level
   addressing (for example by adding OPES functional capabilities to an
   interception proxy) may defeat many protective mechanisms and
   safeguards built into the OPES architecture.

2.2 OPES Flow Application Level Threats

   At the content level threats to the OPES system can come from
   outsiders or insiders.  The threat from outsiders is always
   intentional.  Threats from insiders can be intentional or due to
   inappropriate implementations such as programming and configuration
   errors that result in bad system behavior.

   Application level problems and threats to the OPES systems are
   discussed below:

2.2.1 Unauthorized OPES entities

   Although one party authorization is mandated by the OPES =
architecture
   such authorization  occurs out-of-band.  Discovering the presence of
   an OPES entity and verifying authorization requires special actions
   and may present a problem.

   Adding notification and authorization information to the data
   messages (by using base protocol extensions) may help, especially if
   the UserAgent software is aware of such extensions.

2.2.2 Unauthorized actions of legitimate OPES entities

   According to the OPES architecture the authorization is not tightly
   coupled with specific rules and procedures triggered by the rules.
   Even if a requirement to approve each particular rule and procedure
   was set it looks at least impractical if not impossible to request
   such a permission from the end user.  The authorization is given
   essentially for the class of transformations.  The actual rules and
   triggered procedures may (maliciously or due to a programming error)
   perform actions that they are not authorized for.





Barbir , et al.          Expires April 20, 2003                 [Page =
8]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


2.2.3 Unwanted content transformations

   An authorized OPES service may perform actions that do not adhere to
   the expectations of the party that gave the authorization for the
   service.  Examples may include ad flooding by a local ad insertion
   service or use of inappropriate policy by a content filtering
   service.

   On the other hand an OPES entity acting on behalf of one party may
   perform transformations that another party deems inappropriate.
   Examples may include replacing ads initially inserted by the content
   provider or applying filtering transformations that change the
   meaning of the text.

2.2.4 Corrupted content

   The OPES system may deliver outdated or otherwise distorted
   information due to programming problems or as a result of malicious
   attacks.  For example, a compromised server, instead of performing
   OPES service, may inject a bogus content.  Such actions may be an =
act
   of cyber-vandalism (including virus injection) or intentional
   distribution of misleading information (such as manipulations with
   financial data).

   A compromised OPES server or malicious entity in the data flow may
   introduce changes specifically intended to cause improper actions in
   the OPES server or callout server.  These changes may be in the
   message body, headers or both.  This type of threat is discussed in
   more detail below.

2.2.5 Threats to message structure integrity

   An OPES server may add, remove or delete certain headers in a =
request
   and/or response message (for example to implement additional privacy
   protection or assist in content filtering).  Such changes may =
violate
   end-to-end integrity requirements or defeat services that use
   information provided in such headers (for example some local
   filtering services or reference-based services).


2.2.6 Granularity of protection

   OPES services have implicit permission to modify content.  However,
   the permissions generally apply only to portions of the content, for
   example, URL's between particular HTML tags, or text in headlines, =
or
   URL's matching particular patterns.  In order to express such
   policies, one must be able to refer to portions of messages and to
   detect modifications to message parts.



Barbir , et al.          Expires April 20, 2003                 [Page =
9]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


   Because there is currently very little support for policies that are
   expressed in terms of message parts, it will be difficult to
   attribute any particular modification to a particular OPES =
processor,
   or to automatically detect policy violations.

   A fine-grained policy language should be devised, and it could be
   enforced using digital signatures.  This would avoid the problems
   inherent in hop-by-hop data integrity measures.

2.2.7 Risks of hop-by-hop protections

   OPES services cannot be applied to data protected with end-to-end
   encryption methods because, by definition, the decryption key cannot
   be shared with intermediaries.  This means that if the endpoint
   policies permit OPES services, the data must either be transmitted
   without confidentiality protections or else with an alternative to
   end-to-end encryption: hop-by-hop encryption.  In the latter case,
   all the parties in the OPES processing path must understand the
   encryption requirement and negotiate encrypted connections with =
their
   OPES partners.

   Hop-by-hop protection is less effective than end-to-end protection,
   because any processor in the path can violate the confidentiality or
   integrity of the data without detection.

   If a pair of processors in the delivery path use weak cryptography =
or
   manage keys poorly, there is a danger of data leakage.  For this
   reason, different cryptographic keys should be used for each leg of
   the data stream.

   Even if the data is not confidential, one might desire some checks =
on
   data integrity, to avoid modifications by unauthorized parties.  The
   comments above apply to the use of end-to-end integrity, if it is
   based on shared-key cryptography.  Again, it should be possible to
   use hop-by-hop data integrity to protect data as it moves between
   protection domains.

   Currently there is no method to signal hop-by-hop encryption
   requirements.  Either this must be added to the application =
protocol,
   or OPES must define its own signaling protocol, or all OPES traffic
   MUST ALWAYS be encrypted.

2.2.8 Threats to integrity of complex data

   The OPES system may violate data integrity by applying inconsistent
   transformations to interrelated data objects or references within =
the
   data object.  Problems may range from a broken reference structure
   (modified/missing targets, references to wrong locations or missing



Barbir , et al.          Expires April 20, 2003                [Page =
10]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


   documents) to deliberate replacement/deletion/insertion of links =
that
   violate intentions of the content provider.


2.2.9 Denial of Service (DoS)

   The data consumer application may not be able to access data if the
   OPES system fails for any reason.

   A malicious or malfunctioning node may be able to block all traffic.
   The data traffic destined for the OPES intermediary (or callout
   server) may not be able to use the services of the OPES device.  The
   DoS may be achieved by preventing the data traffic from reaching the
   intermediary or the callout server.

2.2.10 Tracing and notification information

   Inadequate or vulnerable implementation of the tracing and
   notification mechanisms may defeat safeguards built into the OPES
   architecture.

   Tracing and notification facilities may become a target of malicious
   attack.  Such an attack may  create problems in discovering and
   stopping other attacks.

   The absence of a standard for tracing and notification information
   may present an additional problem.  This information is produced and
   consumed by the independent entities (OPES servers/user agents/
   content provider facilities).  This calls for a set of standards
   related to each base protocol in use.





















Barbir , et al.          Expires April 20, 2003                [Page =
11]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


3. Threats to out-of-band data

   The OPES architecture separates a data flow from a control
   information flow (loading rulesets, trust establishment, tracing,
   policy propagation, etc.).  There are certain requirements set but =
no
   specific mechanism is prescribed.  This gives more flexibility for
   implementations but creates more burden for implementors and
   potential customers to ensure that specific implementation meets all
   requirements for data security, entity authentication and action
   authorization.

   In addition to performing correct actions on the OPES data flow any
   OPES implementation has to provide an adequate mechanism to satisfy
   requirements for out-of-band data and signaling information
   integrity.

   Whatever the specific mechanism may be, it inevitably becomes =
subject
   to multiple security threats and possible attacks.  The way the
   threats and attacks may be realized depends on implementation
   specifics but the resulting harm generally falls into two =
categories:
   threats to OPES data flow and threats to data integrity.

   The specific threats are:

3.1 Threats that endanger OPES data flow

   Any weakness in security, authentication and authorization mechanism
   implementation may open a possibility to threats and attacks
   described in section 2.

   An OPES system implementation should address all these threats and
   prove its robustness and ability to withstand malicious attacks or
   networking and programming problems.

3.2 Inaccurate Accounting Information

   Collecting and reporting accurate accounting data may be vital when
   OPES servers are used to extend a business model of content =
provider,
   service provider or as a basis  for third party service.  Ability to
   collect and process accounting data is an important part of OPES
   system functionality.  This functionality may be challenged by
   distortion or destruction of base accounting data (usually logs),
   processed accounting data, accounting parameters and reporting
   configuration.

   As a result a data consumer may be inappropriately charged for
   viewing content that was not successfully delivered, or a content
   provider or independent OPES services provider may not be =
compensated



Barbir , et al.          Expires April 20, 2003                [Page =
12]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


   for the services performed.

   OPES system may use accounting information to distribute resources
   between different consumers or limit resource usage by a specific
   consumer.  In this case an attack on accounting system (by =
distortion
   of data or issuing false configuration commands) may result in
   incorrect resource management and DoS by artificial resource
   starvation.

3.3 OPES service request repudiation

   An entity (producer or consumer) that is authorized to make a =
certain
   request to the OPES intermediary claims, later, that it did not make
   that request.  As a result an OPES entity may be held liable for
   unauthorized changes to the data flow.


3.4 Exposure of private information

   The OPES system may inadvertently or maliciously expose private
   information such as (passwords, buying patterns, page views, and
   credit card numbers) of the data consumer.  Logs and accounting data
   may also contain sensitive private information.


3.5 Inconsistent privacy policy

   The OPES entities may have privacy policy not consistent with end
   user or content provider expectations.

   Privacy related problems may be further complicated if OPES =
entities,
   content providers and end users belong to different jurisdictions
   with different requirements and different levels of legal =
protection.
   As aresult the end user may not be aware that he/she does not have
   the expected  legal protection.  The content provider may be exposed
   to legal risks due to a failure to comply with regulation which he =
is
   not even aware of.

3.6 Exposure of privacy preferences

   The OPES system may inadvertently or maliciously expose end user
   privacy settings and requirements.

3.7 Exposure of security settings

   There are risks that the OPES system may expose end user security
   settings when handling the request and responses.




Barbir , et al.          Expires April 20, 2003                [Page =
13]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


3.8 Improper enforcement of privacy and security policy

   OPES entities are part of the content distribution system and as =
such
   take on certain obligations to support security and privacy policies
   mandated by content producer and/or end user.  However there is a
   danger that these policies are not properly implemented and =
enforced.
   The data consumer application may not be aware that its protections
   are no longer in effect.

   Privacy and security related parts of the systems are most often
   targeted by malicious attacks and ability to withstand such attacks
   is of paramount importance.







































Barbir , et al.          Expires April 20, 2003                [Page =
14]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


4. Problems related to the cryptographic data protection


















































Barbir , et al.          Expires April 20, 2003                [Page =
15]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


5. Security Considerations

   This document discusses multiple security and privacy issues related
   to the OPES services.















































Barbir , et al.          Expires April 20, 2003                [Page =
16]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


References

   [1]  A. Barbir et. al, "An Architecture for Open Pluggable Edge
        Services (OPES)", Internet-Draft: http://www.ietf.org/internet-
        drafts/draft-ietf-opes-architecture-03.txt, Aug 2002.

   [2]  A. Barbir et. al, "OPES Use Cases and Deployment Scenarios",
        Internet-Draft: http://www.ietf.org/internet-drafts/draft-ietf-
        opes-architecture-02.txt, July 2002.

   [3]  A. Barbir et. al, "Requirements for Policy, Authorization  and
        Enforcement of OPES Services", Internet-Draft: http://
        www.ietf.org/internet-  drafts/draft-ietf-opes-authorization-
        00.txt , October  2002.

   [4]  Floyd, S. and L. Daigle, "IAB Architectural and Policy
        Considerations for Open Pluggable Edge Services", RFC 3238,
        January 2002.

   [5]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
        Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
        HTTP/1.1", RFC 2616, June 1999.

   [6]  Cooper, I., "Internet Web Replication and Caching Taxonomy", =
RFC
        3040, January 2001.


Authors' Addresses

   Abbie Barbir
   Nortel Networks
   3500 Carling Avenue
   Nepean, Ontario  K2H 8E9
   Canada

   Phone: +1 613 763 5229
   EMail: abbieb@nortelnetworks.com


   Oskar Batuner
   Independent consultant



   EMail: batuner@attbi.com






Barbir , et al.          Expires April 20, 2003                [Page =
17]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


   Tat Chan
   Nokia
   5 Wayside Road
   Burlington, MA  01803
   USA

   EMail: Tat.Chan@nokia.com


   Bindignavile Srinivas
   Nokia
   5 Wayside Road
   Burlington, MA  01803
   USA

   EMail: bindignavile.srinivas@nokia.com


   Hilarie Orman
   Purple Streak Development



   Phone:
   EMail: ho@alum.mit.edu


























Barbir , et al.          Expires April 20, 2003                [Page =
18]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


Appendix A. Acknowledgements

   TBD
















































Barbir , et al.          Expires April 20, 2003                [Page =
19]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph =
are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Barbir , et al.          Expires April 20, 2003                [Page =
20]
=0C




------_=_NextPart_000_01C2783A.21B9889E--


From owner-ietf-openproxy@mail.imc.org  Sun Oct 20 14:56:14 2002
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01612
	for <opes-archive@ietf.org>; Sun, 20 Oct 2002 14:56:11 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g9KIMFp01437
	for ietf-openproxy-bks; Sun, 20 Oct 2002 11:22:15 -0700 (PDT)
Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g9KIMEW01432
	for <ietf-openproxy@imc.org>; Sun, 20 Oct 2002 11:22:14 -0700 (PDT)
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9KIM5K21968;
	Sun, 20 Oct 2002 14:22:06 -0400 (EDT)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <TLKCGRDD>; Sun, 20 Oct 2002 14:22:05 -0400
Message-ID: <87609AFB433BD5118D5E0002A52CD75403E3FB81@zcard0k6.ca.nortel.com>
From: "Abbie Barbir" <abbieb@nortelnetworks.com>
To: "'internet-drafts@ietf.org'" <internet-drafts@ietf.org>
Cc: "'ietf-openproxy@imc.org'" <ietf-openproxy@imc.org>,
        "Abbie Barbir" <abbieb@nortelnetworks.com>,
        "'Markus Hofmann'" <markus@mhof.com>,
        "'Marshall Rose'" <mrose@dbc.mtview.ca.us>
Subject: Publish Draft: draft-ietf-opes-threats-01
Date: Sun, 20 Oct 2002 14:22:04 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C27865.9521CFAA"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C27865.9521CFAA
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C27865.9521CFAA"


------_=_NextPart_001_01C27865.9521CFAA
Content-Type: text/plain

Please publish the attached as an Internet Draft 
draft-ietf-opes-threats-01 <<draft-ietf-opes-threats-01.txt>> 
thanks 

abbie

------_=_NextPart_001_01C27865.9521CFAA
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>Publish Draft: draft-ietf-opes-threats-01</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Times New Roman">Please publish the attached =
as an Internet Draft</FONT><FONT FACE=3D"Times New Roman"> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">draft-ietf-opes-threats-01<FONT =
FACE=3D"Arial" SIZE=3D2 COLOR=3D"#000000"> =
&lt;&lt;draft-ietf-opes-threats-01.txt&gt;&gt; </FONT></FONT>
<BR><FONT SIZE=3D2 FACE=3D"Times New Roman">thanks</FONT><FONT =
FACE=3D"Times New Roman"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">abbie</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C27865.9521CFAA--

------_=_NextPart_000_01C27865.9521CFAA
Content-Type: text/plain;
	name="draft-ietf-opes-threats-01.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-opes-threats-01.txt"
Content-Transfer-Encoding: quoted-printable



Network Working Group                                         A. Barbir
Internet-Draft                                           Nortel =
Networks
Expires: April 20, 2003                                       O. =
Batuner
                                                  Independent =
consultant
                                                                 T. =
Chan
                                                             B. =
Srinivas
                                                                   =
Nokia
                                                                H. =
Orman
                                               Purple Streak =
Development
                                                        October 20, =
2002


      Security Threats and Risks for Open Pluggable Edge Services
                       draft-ietf-opes-threats-01

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six =
months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 20, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   The document investigates the security threats associated with OPES.
   The effects of security threats on the underlying architecture are
   discussed.  The document does not specify or recommend any =
solutions.
   Proposed solutions are viewed as illustrations of the nature of
   threats.



Barbir , et al.          Expires April 20, 2003                 [Page =
1]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


Table of Contents

   1.     Introduction . . . . . . . . . . . . . . . . . . . . . . .   =
3
   2.     OPES Data Flow Threats . . . . . . . . . . . . . . . . . .   =
5
   2.1    OPES Flow Network Level Threats  . . . . . . . . . . . . .   =
6
   2.1.1  OPES device spoofing . . . . . . . . . . . . . . . . . . .   =
6
   2.1.2  Remote callout server spoofing . . . . . . . . . . . . . .   =
7
   2.1.3  Session Hijacking  . . . . . . . . . . . . . . . . . . . .   =
7
   2.1.4  Threats to data confidentiality (eavesdropping)  . . . . .   =
7
   2.1.5  Denial-of-Service (DoS)  . . . . . . . . . . . . . . . . .   =
7
   2.1.6  Threats to network robustness  . . . . . . . . . . . . . .   =
8
   2.2    OPES Flow Application Level Threats  . . . . . . . . . . .   =
8
   2.2.1  Unauthorized OPES entities . . . . . . . . . . . . . . . .   =
8
   2.2.2  Unauthorized actions of legitimate OPES entities . . . . .   =
8
   2.2.3  Unwanted content transformations . . . . . . . . . . . . .   =
9
   2.2.4  Corrupted content  . . . . . . . . . . . . . . . . . . . .   =
9
   2.2.5  Threats to message structure integrity . . . . . . . . . .   =
9
   2.2.6  Granularity of protection  . . . . . . . . . . . . . . . .   =
9
   2.2.7  Risks of hop-by-hop protection . . . . . . . . . . . . . .  =
10
   2.2.8  Threats to integrity of complex data . . . . . . . . . . .  =
10
   2.2.9  Denial of Service (DoS)  . . . . . . . . . . . . . . . . .  =
11
   2.2.10 Tracing and notification information . . . . . . . . . . .  =
11
   3.     Threats to out-of-band data  . . . . . . . . . . . . . . .  =
12
   3.1    Threats that endanger OPES data flow . . . . . . . . . . .  =
12
   3.2    Inaccurate Accounting Information  . . . . . . . . . . . .  =
12
   3.3    OPES service request repudiation . . . . . . . . . . . . .  =
13
   3.4    Exposure of private information  . . . . . . . . . . . . .  =
13
   3.5    Inconsistent privacy policy  . . . . . . . . . . . . . . .  =
13
   3.6    Exposure of privacy preferences  . . . . . . . . . . . . .  =
13
   3.7    Exposure of security settings  . . . . . . . . . . . . . .  =
13
   3.8    Improper enforcement of privacy and security policy  . . .  =
14
   4.     Security Considerations  . . . . . . . . . . . . . . . . .  =
15
          References . . . . . . . . . . . . . . . . . . . . . . . .  =
16
          Authors' Addresses . . . . . . . . . . . . . . . . . . . .  =
16
   A.     Acknowledgements . . . . . . . . . . . . . . . . . . . . .  =
18
          Full Copyright Statement . . . . . . . . . . . . . . . . .  =
19















Barbir , et al.          Expires April 20, 2003                 [Page =
2]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


1. Introduction

   The Open Pluggable Edge Services (OPES) [1]  architecture enables
   cooperative application services (OPES services) between a data
   provider, a data consumer, and zero or more OPES processors.  The
   application services under consideration analyze and possibly
   transform application-level messages exchanged between the data
   provider and the data consumer.  The OPES processor can distribute
   the responsibility of service execution by communicating and
   collaborating with one or more remote callout servers.  The details
   of the OPES architecture can be found in  [1].

   Security threats with respect to OPES can be viewed from different
   angles.  There are security risks that affect content consumer
   applications, and those that affect the data provider applications.
   These threats affect the quality and integrity of data that the
   applications either produce or consume.  On the other hand, the
   security risks can also be categorized into trust within the system
   (i.e.  OPES service providers) and protection of the system from
   threats imposed by outsiders such as hackers and attackers.  =
Insiders
   are those parties that are part of the OPES system.  Outsiders are
   those entities that are not participating in the OPES system.

   It is up to OPES service providers to verify the trust relationship
   between them, whereby intentional false information is tracked.
   Insiders can intentionally or unintentionally inflect harm and =
damage
   on the data consumer and data provider applications.  This can be
   through bad system configuration, execution of bad software or, if
   their networks are compromised, by hackers.

   Depending on the deployment scenario, the trust within the OPES
   system is based on a transitive trust between the data provider
   application, the OPES entities and the data consumer application.
   Threats to OPES entities can be at the OPES flow level and/or at the
   network level.

   In considering threats to the OPES system, the document will follow =
a
   threat analysis model that identifies the threats from the
   prospective of how it will affect the data consumer and the data
   provider applications.

   The main goal of this document is threat discovery and analysis.  =
The
   document does not specify or recommend any solutions.  Proposed
   solutions are viewed as illustrations of the nature of threats.

   It is important to mention that the OPES architecture has many
   similarities with other so called overlay networks, specifically web
   caches and content delivery networks (CDN) (see [2] , [4] ).  This



Barbir , et al.          Expires April 20, 2003                 [Page =
3]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


   document focuses on threats that are introduced by the existence of
   the OPES processor and callout servers.  Security threats specific =
to
   content services that do not use the OPES architecture are =
considered
   out-of-scope of this document.  However, this document can be used =
as
   input when considering security implications for web caches and =
CDNs.

   The document is organized as follows: Section 2 discusses threats to
   OPES data flow on network and application level, section 3 discusses
   threats to other parts of the system and section 4 discusses =
problems
   related to the cryptographic data protection paying special =
attention
   to the hop-by-hop versus end-to-end protection.








































Barbir , et al.          Expires April 20, 2003                 [Page =
4]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


2. OPES Data Flow Threats

   Threats to OPES data flow can affect the data consumer and data
   provider applications.  At the OPES flow level, threats can occur at
   Policy Enforcement Points and Policy Decision Points [3]  and along
   the OPES flow path where networks elements are used to process the
   data.

   A serious problem is posed by the very fact that the OPES
   architecture is based on widely adopted protocols (HTTP is used as =
an
   example).  The architecture document specifically requires that "the
   presence of an OPES processor in the data request/response flow =
SHALL
   NOT interfere with the operations of non-OPES aware clients and
   servers".  This greatly facilitates OPES deployment but on the other
   hand a vast majority of clients (browsers) will not be able to
   exploit any safeguards added as a base protocol extensions.

   In reality active investigative actions are not feasible for the
   regular end user (Where this content comes from? Can I get it =
another
   way? What is the difference? Is it legitimate?).  Even if there are
   facilities and technical expertise present to pursue these questions
   such thorough examination of each result is prohibitively expensive
   in terms of time and effort.  OPES-aware content providers may try =
to
   protect themselves by adding verification scripts and special page
   structures.  OPES-aware end users may use special tools.  In all
   other cases (non-OPES aware clients and servers) protection will =
rely
   on monitoring services and investigation of occasionally discovered
   accidents.

   OPES system poses a special danger as a possible base for classical
   man-in-the-middle attack.  One of the reasons why such attacks are
   relatively rare is difficulty in finding an appropriate base: a
   combination of a traffic interception point controlling consistent
   flow of data and an application codebase with sufficient performance
   to analyze and possible modify all passing data.  OPES processor
   perfectly meets this definition.  This calls for a special attention
   to protection measures at all levels of the system.

   Any break into an OPES processor or remote callout server can have a
   ripple effect on the integrity of the affected OPES services across
   all service providers that use the service.  To mitigate this threat
   appropriate security procedures and tools (e.g., a firewall) should
   be applied.

   Specific threats can be at the network level and at OPES data flow
   level.





Barbir , et al.          Expires April 20, 2003                 [Page =
5]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


2.1 OPES Flow Network Level Threats

   OPES processor and callout servers are susceptible to network level
   attacks from outsiders or from the networks of other OPES service
   providers (i.e.  if the network of a contracted OPES service is
   compromised).

   OPES architecture is based on common application protocols that do
   not provide strong guarantees of privacy, authentication, or
   integrity.  The IAB considerations [4]  require that the IP address
   of an OPES processor be accessible to data consumer applications at
   the IP level.  This exposes the OPES processor including remote
   callout servers to network level attacks.  Use of TCP/IP as network
   level protocol makes OPES processors subject to many known attacks,
   like IP spoofing and session stealing.

   The OPES system is also susceptible to a number of security threats
   that are commonly associated with network infrastructure.  These
   threats include snooping, denial of service, sabotage, vandalism,
   industrial espionage, theft of service and inadequate system
   configuration that leaves unneeded ports and services open to the
   public.

   There are best practice solutions to mitigate network level threats.
   It is recommended that the security of the OPES entities at the
   network level be enhanced using known techniques and methods that
   minimize the risks of IP spoofing, snooping, denial of service and
   session stealing.

   In the following subsections we take a more detailed look at these
   threats and potential resulting harm.

2.1.1 OPES device spoofing

   A malicious node could send false information about itself
   masquerading as an OPES device.  Alternatively, despite the presence
   of a genuine OPES device which has been authenticated, the actual
   data transformation could be performed in a malicious colocated
   callout server which is resident in the same administrative domain =
as
   the OPES device.  Furthermore, the malicious node could force the
   consumer or producer to use the services of a malicious OPES
   processor, which might render undesired or very expensive
   transformation services.

   As a consequence, the malicious device would be able to eavesdrop on
   all traffic between the end-systems.  In addition, unexpected and
   undesirable data transformation by the malicious processor or =
callout
   server would result.  Finally, the malicious entity, that



Barbir , et al.          Expires April 20, 2003                 [Page =
6]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


   successfully spoofs an OPES processor (or callout server), may =
refuse
   to forward the legitimate traffic to the content consumers, =
resulting
   in a Denial-of-Service attack.

2.1.2 Remote callout server spoofing

   Similar to the threat described in 2.1.1, a malicious node could
   masquerade as a remote callout server.  Despite the presence of an
   authenticated OPES device, the malicious data transformation could =
be
   performed in a remote callout server.

   The effect of having such a malicious remote callout server is very
   similar to those produced by having a malicious OPES device or
   colocated callout server (see 2.1.1).

2.1.3 Session Hijacking

   If a TCP/IP session is hijacked by an attacker, it would be possible
   for the hijacker to compromise the integrity of content on an OPES
   processor.

2.1.4 Threats to data confidentiality (eavesdropping)

   An eavesdropper is typically capable of snooping on fields within
   messages in transit.  Using various eavesdropping techniques, he may
   be able to garner various kinds of information including topology/
   location/IP addresses etc.  that may not be desirable to divulge.  =
He
   also may be able to eavesdrop on the content messages being =
delivered
   to the consumer.  Furthermore, to ensure secure data traversal from
   the provider to the consumer, authentication information must be
   exchanged between the provider and the consumer.  When such security
   related information has to traverse through an OPES system, it is
   also subject to the threat of being eavesdropped on by the malicious
   entity.

2.1.5 Denial-of-Service (DoS)

   The processor or the callout server can be overloaded by spurious
   service requests issued by a malicious node, which denies the legal
   data traffic the necessary resources to render service.  The
   resources include CPU cycles, memory, network interfaces, etc.  A
   Denial-of-Service attack can be selective, generic or random in =
terms
   of which communication streams are affected.

   Distributed DoS is also possible when an attacker successfully
   directs multiple nodes over the network to initiate spurious service
   requests to an OPES processor  (or call-out server) simultaneously.




Barbir , et al.          Expires April 20, 2003                 [Page =
7]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


2.1.6 Threats to network robustness

   if OPES implementation does violate end-to-end addressing =
principles,
   it could endangers the Internet infrastructure by complicating
   routing and connection management.  If it does not use flow-control
   principles for managing connections, or if it interferes with =
end-to-
   end flow control of connections that it did not originate, then it
   could causing Internet congestion.

   An implementation that violates IAB requirement of explicit IP level
   addressing (for example by adding OPES functional capabilities to an
   interception proxy) may defeat many protective mechanisms and
   safeguards built into the OPES architecture.

2.2 OPES Flow Application Level Threats

   At the content level threats to the OPES system can come from
   outsiders or insiders.  The threat from outsiders is always
   intentional.  Threats from insiders can be intentional or due to
   inappropriate implementations such as programming and configuration
   errors that result in bad system behavior.

   Application level problems and threats to the OPES systems are
   discussed below:

2.2.1 Unauthorized OPES entities

   Although one party authorization is mandated by the OPES =
architecture
   such authorization  occurs out-of-band.  Discovering the presence of
   an OPES entity and verifying authorization requires special actions
   and may present a problem.

   Adding notification and authorization information to the data
   messages (by using base protocol extensions) may help, especially if
   the UserAgent software is aware of such extensions.

2.2.2 Unauthorized actions of legitimate OPES entities

   According to the OPES architecture the authorization is not tightly
   coupled with specific rules and procedures triggered by the rules.
   Even if a requirement to approve each particular rule and procedure
   was set it looks at least impractical if not impossible to request
   such a permission from the end user.  The authorization is given
   essentially for the class of transformations.  The actual rules and
   triggered procedures may (maliciously or due to a programming error)
   perform actions that they are not authorized for.





Barbir , et al.          Expires April 20, 2003                 [Page =
8]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


2.2.3 Unwanted content transformations

   An authorized OPES service may perform actions that do not adhere to
   the expectations of the party that gave the authorization for the
   service.  Examples may include ad flooding by a local ad insertion
   service or use of inappropriate policy by a content filtering
   service.

   On the other hand an OPES entity acting on behalf of one party may
   perform transformations that another party deems inappropriate.
   Examples may include replacing ads initially inserted by the content
   provider or applying filtering transformations that change the
   meaning of the text.

2.2.4 Corrupted content

   The OPES system may deliver outdated or otherwise distorted
   information due to programming problems or as a result of malicious
   attacks.  For example, a compromised server, instead of performing
   OPES service, may inject a bogus content.  Such actions may be an =
act
   of cyber-vandalism (including virus injection) or intentional
   distribution of misleading information (such as manipulations with
   financial data).

   A compromised OPES server or malicious entity in the data flow may
   introduce changes specifically intended to cause improper actions in
   the OPES server or callout server.  These changes may be in the
   message body, headers or both.  This type of threat is discussed in
   more detail below.

2.2.5 Threats to message structure integrity

   An OPES server may add, remove or delete certain headers in a =
request
   and/or response message (for example to implement additional privacy
   protection or assist in content filtering).  Such changes may =
violate
   end-to-end integrity requirements or defeat services that use
   information provided in such headers (for example some local
   filtering services or reference-based services).


2.2.6 Granularity of protection

   OPES services have implicit permission to modify content.  However,
   the permissions generally apply only to portions of the content, for
   example, URL's between particular HTML tags, or text in headlines, =
or
   URL's matching particular patterns.  In order to express such
   policies, one must be able to refer to portions of messages and to
   detect modifications to message parts.



Barbir , et al.          Expires April 20, 2003                 [Page =
9]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


   Because there is currently very little support for policies that are
   expressed in terms of message parts, it will be difficult to
   attribute any particular modification to a particular OPES =
processor,
   or to automatically detect policy violations.

   A fine-grained policy language should be devised, and it could be
   enforced using digital signatures.  This would avoid the problems
   inherent in hop-by-hop data integrity measures.

2.2.7 Risks of hop-by-hop protection

   OPES services cannot be applied to data protected with end-to-end
   encryption methods because, by definition, the decryption key cannot
   be shared with opes processors.  This means that if the endpoint
   policies permit OPES services, the data must either be transmitted
   without confidentiality protections or else with an alternative to
   end-to-end encryption: hop-by-hop encryption.  In the latter case,
   all the parties in the OPES processing path must understand the
   encryption requirement and negotiate encrypted connections with =
their
   OPES partners.

   Hop-by-hop protection is less effective than end-to-end protection,
   because any processor in the path can violate the confidentiality or
   integrity of the data without detection.

   If a pair of processors in the delivery path use weak cryptography =
or
   manage keys poorly, there is a danger of data leakage.  For this
   reason, different cryptographic keys should be used for each leg of
   the data stream.

   Even if the data is not confidential, one might desire some checks =
on
   data integrity, to avoid modifications by unauthorized parties.  The
   comments above apply to the use of end-to-end integrity, if it is
   based on shared-key cryptography.  Again, it should be possible to
   use hop-by-hop data integrity to protect data as it moves between
   protection domains.

   Currently there is no method to signal hop-by-hop encryption
   requirements.  Either this must be added to the application =
protocol,
   or OPES must define its own signaling protocol, or all OPES traffic
   MUST ALWAYS be encrypted.

2.2.8 Threats to integrity of complex data

   The OPES system may violate data integrity by applying inconsistent
   transformations to interrelated data objects or references within =
the
   data object.  Problems may range from a broken reference structure
   (modified/missing targets, references to wrong locations or missing



Barbir , et al.          Expires April 20, 2003                [Page =
10]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


   documents) to deliberate replacement/deletion/insertion of links =
that
   violate intentions of the content provider.


2.2.9 Denial of Service (DoS)

   The data consumer application may not be able to access data if the
   OPES system fails for any reason.

   A malicious or malfunctioning node may be able to block all traffic.
   The data traffic destined for the OPES processor  (or callout =
server)
   may not be able to use the services of the OPES device.  The DoS may
   be achieved by preventing the data traffic from reaching the
   processor  or the callout server.

2.2.10 Tracing and notification information

   Inadequate or vulnerable implementation of the tracing and
   notification mechanisms may defeat safeguards built into the OPES
   architecture.

   Tracing and notification facilities may become a target of malicious
   attack.  Such an attack may  create problems in discovering and
   stopping other attacks.

   The absence of a standard for tracing and notification information
   may present an additional problem.  This information is produced and
   consumed by the independent entities (OPES servers/user agents/
   content provider facilities).  This calls for a set of standards
   related to each base protocol in use.





















Barbir , et al.          Expires April 20, 2003                [Page =
11]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


3. Threats to out-of-band data

   The OPES architecture separates a data flow from a control
   information flow (loading rulesets, trust establishment, tracing,
   policy propagation, etc.).  There are certain requirements set but =
no
   specific mechanism is prescribed.  This gives more flexibility for
   implementations but creates more burden for implementors and
   potential customers to ensure that specific implementation meets all
   requirements for data security, entity authentication and action
   authorization.

   In addition to performing correct actions on the OPES data flow any
   OPES implementation has to provide an adequate mechanism to satisfy
   requirements for out-of-band data and signaling information
   integrity.

   Whatever the specific mechanism may be, it inevitably becomes =
subject
   to multiple security threats and possible attacks.  The way the
   threats and attacks may be realized depends on implementation
   specifics but the resulting harm generally falls into two =
categories:
   threats to OPES data flow and threats to data integrity.

   The specific threats are:

3.1 Threats that endanger OPES data flow

   Any weakness in security, authentication and authorization mechanism
   implementation may open a possibility to threats and attacks
   described in section 2.

   An OPES system implementation should address all these threats and
   prove its robustness and ability to withstand malicious attacks or
   networking and programming problems.

3.2 Inaccurate Accounting Information

   Collecting and reporting accurate accounting data may be vital when
   OPES servers are used to extend a business model of content =
provider,
   service provider or as a basis  for third party service.  Ability to
   collect and process accounting data is an important part of OPES
   system functionality.  This functionality may be challenged by
   distortion or destruction of base accounting data (usually logs),
   processed accounting data, accounting parameters and reporting
   configuration.

   As a result a data consumer may be inappropriately charged for
   viewing content that was not successfully delivered, or a content
   provider or independent OPES services provider may not be =
compensated



Barbir , et al.          Expires April 20, 2003                [Page =
12]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


   for the services performed.

   OPES system may use accounting information to distribute resources
   between different consumers or limit resource usage by a specific
   consumer.  In this case an attack on accounting system (by =
distortion
   of data or issuing false configuration commands) may result in
   incorrect resource management and DoS by artificial resource
   starvation.

3.3 OPES service request repudiation

   An entity (producer or consumer) that is authorized to make a =
certain
   request to the OPES processor  claims, later, that it did not make
   that request.  As a result an OPES entity may be held liable for
   unauthorized changes to the data flow.


3.4 Exposure of private information

   The OPES system may inadvertently or maliciously expose private
   information such as (passwords, buying patterns, page views, and
   credit card numbers) of the data consumer.  Logs and accounting data
   may also contain sensitive private information.


3.5 Inconsistent privacy policy

   The OPES entities may have privacy policy not consistent with end
   user or content provider expectations.

   Privacy related problems may be further complicated if OPES =
entities,
   content providers and end users belong to different jurisdictions
   with different requirements and different levels of legal =
protection.
   As a result the end user may not be aware that he/she does not have
   the expected  legal protection.  The content provider may be exposed
   to legal risks due to a failure to comply with regulation which he =
is
   not even aware of.

3.6 Exposure of privacy preferences

   The OPES system may inadvertently or maliciously expose end user
   privacy settings and requirements.

3.7 Exposure of security settings

   There are risks that the OPES system may expose end user security
   settings when handling the request and responses.




Barbir , et al.          Expires April 20, 2003                [Page =
13]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


3.8 Improper enforcement of privacy and security policy

   OPES entities are part of the content distribution system and as =
such
   take on certain obligations to support security and privacy policies
   mandated by content producer and/or end user.  However there is a
   danger that these policies are not properly implemented and =
enforced.
   The data consumer application may not be aware that its protections
   are no longer in effect.

   Privacy and security related parts of the systems are most often
   targeted by malicious attacks and ability to withstand such attacks
   is of paramount importance.







































Barbir , et al.          Expires April 20, 2003                [Page =
14]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


4. Security Considerations

   This document discusses multiple security and privacy issues related
   to the OPES services.















































Barbir , et al.          Expires April 20, 2003                [Page =
15]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


References

   [1]  A. Barbir et. al, "An Architecture for Open Pluggable Edge
        Services (OPES)", Internet-Draft: http://www.ietf.org/internet-
        drafts/draft-ietf-opes-architecture-03.txt, Aug 2002.

   [2]  A. Barbir et. al, "OPES Use Cases and Deployment Scenarios",
        Internet-Draft: http://www.ietf.org/internet-drafts/draft-ietf-
        opes-architecture-02.txt, July 2002.

   [3]  A. Barbir et. al, "Requirements for Policy, Authorization  and
        Enforcement of OPES Services", Internet-Draft: http://
        www.ietf.org/internet-  drafts/draft-ietf-opes-authorization-
        00.txt , October  2002.

   [4]  Floyd, S. and L. Daigle, "IAB Architectural and Policy
        Considerations for Open Pluggable Edge Services", RFC 3238,
        January 2002.

   [5]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
        Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
        HTTP/1.1", RFC 2616, June 1999.

   [6]  Cooper, I., "Internet Web Replication and Caching Taxonomy", =
RFC
        3040, January 2001.


Authors' Addresses

   Abbie Barbir
   Nortel Networks
   3500 Carling Avenue
   Nepean, Ontario  K2H 8E9
   Canada

   Phone: +1 613 763 5229
   EMail: abbieb@nortelnetworks.com


   Oskar Batuner
   Independent consultant



   EMail: batuner@attbi.com






Barbir , et al.          Expires April 20, 2003                [Page =
16]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


   Tat Chan
   Nokia
   5 Wayside Road
   Burlington, MA  01803
   USA

   EMail: Tat.Chan@nokia.com


   Bindignavile Srinivas
   Nokia
   5 Wayside Road
   Burlington, MA  01803
   USA

   EMail: bindignavile.srinivas@nokia.com


   Hilarie Orman
   Purple Streak Development



   Phone:
   EMail: ho@alum.mit.edu


























Barbir , et al.          Expires April 20, 2003                [Page =
17]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


Appendix A. Acknowledgements

   The authors gratefully acknowledge the contributions of: Markus
   Hofmann

   TBD













































Barbir , et al.          Expires April 20, 2003                [Page =
18]
=0C
Internet-Draft    Security Threats and Risks for Open Pluggable Edge =
Services                                     October 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph =
are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Barbir , et al.          Expires April 20, 2003                [Page =
19]
=0C




------_=_NextPart_000_01C27865.9521CFAA--


From owner-ietf-openproxy@mail.imc.org  Mon Oct 21 22:58:20 2002
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22750
	for <opes-archive@ietf.org>; Mon, 21 Oct 2002 22:58:19 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g9M2ZCR03494
	for ietf-openproxy-bks; Mon, 21 Oct 2002 19:35:12 -0700 (PDT)
Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g9M2ZBW03490
	for <ietf-openproxy@imc.org>; Mon, 21 Oct 2002 19:35:11 -0700 (PDT)
Received: from 1cust75.tnt3.nashua.nh.da.uu.net ([65.235.173.75] helo=eburger)
	by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1)
	id 183osz-0005IK-00
	for ietf-openproxy@imc.org; Mon, 21 Oct 2002 19:35:13 -0700
Reply-To: <eburger@snowshore.com>
From: "Eric Burger" <eburger@snowshore.com>
To: "OPES Group" <ietf-openproxy@imc.org>
Subject: Unique Shared Secrets (4.4.2) in opes-authorization
Date: Mon, 21 Oct 2002 22:35:11 -0400
Message-ID: <BEEMKJGAMKLMAIKEECBAMEHIDCAA.eburger@snowshore.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <3D922457.9080103@bell-labs.com>
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


Why must the shared secrets be unique for each requestor / responder pair?
Why do we care?  In fact, such a requirement opens a security hole: I can
guess someone else's key by trying to enter keys until the "system" tells me
I can't because someone else has that key.

I would drop the bullet.



From owner-ietf-openproxy@mail.imc.org  Mon Oct 21 22:58:23 2002
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22764
	for <opes-archive@ietf.org>; Mon, 21 Oct 2002 22:58:22 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g9M2Z9g03487
	for ietf-openproxy-bks; Mon, 21 Oct 2002 19:35:09 -0700 (PDT)
Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g9M2Z8W03483
	for <ietf-openproxy@imc.org>; Mon, 21 Oct 2002 19:35:08 -0700 (PDT)
Received: from 1cust75.tnt3.nashua.nh.da.uu.net ([65.235.173.75] helo=eburger)
	by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1)
	id 183osw-0005IK-00
	for ietf-openproxy@imc.org; Mon, 21 Oct 2002 19:35:11 -0700
Reply-To: <eburger@snowshore.com>
From: "Eric Burger" <eburger@snowshore.com>
To: "OPES Group" <ietf-openproxy@imc.org>
Subject: Authentication Requirements in opes-authorization-00 (section 4.2)
Date: Mon, 21 Oct 2002 22:35:09 -0400
Message-ID: <BEEMKJGAMKLMAIKEECBAKEHIDCAA.eburger@snowshore.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <3D922457.9080103@bell-labs.com>
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


Section 4.2 states, "The service provider MUST keep a log of all requests
for OPES services".

Last I looked, the IETF is a protocol standards body, not a legislative
body.  Unless the *protocol* REQUIRES the service provider to keep the log,
this is an unenforceable requirement.  I agree that we need to state our
sentiment.  A better place may be in the security section.

Likewise, "The trusted users must be authenticated before being allowed to
take actions" is a similar policy, not protocol statement.  The good news is
"must" is not capitalized.  However, this statement again does not belong in
this section, and should be a SHOULD.

The next paragraph is a place where we can have protocol machinery: "The
PEP's should be authenticated before they receive policy rules".  If we
care, then I would propose, "Because of the sensitivity of user profiles,
the PEP Interface between the PEP and the PDP MUST use a secure transport
protocol."



From owner-ietf-openproxy@mail.imc.org  Mon Oct 21 22:58:32 2002
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22796
	for <opes-archive@ietf.org>; Mon, 21 Oct 2002 22:58:32 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g9M2ZED03500
	for ietf-openproxy-bks; Mon, 21 Oct 2002 19:35:14 -0700 (PDT)
Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g9M2ZDW03496
	for <ietf-openproxy@imc.org>; Mon, 21 Oct 2002 19:35:13 -0700 (PDT)
Received: from 1cust75.tnt3.nashua.nh.da.uu.net ([65.235.173.75] helo=eburger)
	by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1)
	id 183ot1-0005IK-00
	for ietf-openproxy@imc.org; Mon, 21 Oct 2002 19:35:15 -0700
Reply-To: <eburger@snowshore.com>
From: "Eric Burger" <eburger@snowshore.com>
To: "OPES Group" <ietf-openproxy@imc.org>
Subject: Privacy Considerations (4.5)  in opes-authorization-00
Date: Mon, 21 Oct 2002 22:35:13 -0400
Message-ID: <BEEMKJGAMKLMAIKEECBAOEHIDCAA.eburger@snowshore.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <3D922457.9080103@bell-labs.com>
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


How can a user know that the PDP has user profiles so they can limit the
promulgation of their profile data?


As pointed out in the thread on Authentication Requirements, how does the
PROTOCOL limit traffic data from being sent to third parties?  How does the
PROTOCOL know the difference between a server run by the service provider
and a server run by a third party?

In the real world, the user and the service provider enter into a trust
agreement (outside of the protocol).  Part of that agreement is that the
service provider can or cannot let third parties do work on their behalf.
This, again, is outside of the protocol.  POLICY dictates whether a service
provider may or may not send traffic data to third parties.



From owner-ietf-openproxy@mail.imc.org  Tue Oct 22 08:09:57 2002
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13207
	for <opes-archive@ietf.org>; Tue, 22 Oct 2002 08:09:56 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g9MBh0K16157
	for ietf-openproxy-bks; Tue, 22 Oct 2002 04:43:00 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g9MBgwW16152
	for <ietf-openproxy@imc.org>; Tue, 22 Oct 2002 04:42:59 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12183;
	Tue, 22 Oct 2002 07:40:43 -0400 (EDT)
Message-Id: <200210221140.HAA12183@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-openproxy@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-opes-threats-00.txt
Date: Tue, 22 Oct 2002 07:40:42 -0400
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF.

	Title		: Security Threats and Risks for Open Pluggable Edge 
                          Services
	Author(s)	: A. Barbir et al.
	Filename	: draft-ietf-opes-threats-00.txt
	Pages		: 19
	Date		: 2002-10-21
	
The document investigates the security threats associated with OPES.
The effects of security threats on the underlying architecture are
discussed.  The document does not specify or recommend any solutions.
Proposed solutions are viewed as illustrations of the nature of
threats.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-opes-threats-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-opes-threats-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-opes-threats-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2002-10-21143323.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-opes-threats-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-opes-threats-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2002-10-21143323.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-ietf-openproxy@mail.imc.org  Tue Oct 22 12:22:22 2002
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24730
	for <opes-archive@ietf.org>; Tue, 22 Oct 2002 12:22:21 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g9MFfAZ02393
	for ietf-openproxy-bks; Tue, 22 Oct 2002 08:41:10 -0700 (PDT)
Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g9MFf9W02389
	for <ietf-openproxy@imc.org>; Tue, 22 Oct 2002 08:41:09 -0700 (PDT)
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9MFerH00945
	for <ietf-openproxy@imc.org>; Tue, 22 Oct 2002 11:40:54 -0400 (EDT)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <TLKCHSX9>; Tue, 22 Oct 2002 11:40:54 -0400
Message-ID: <87609AFB433BD5118D5E0002A52CD75403EA556B@zcard0k6.ca.nortel.com>
From: "Abbie Barbir" <abbieb@nortelnetworks.com>
To: ietf-openproxy@imc.org
Cc: "Abbie Barbir" <abbieb@nortelnetworks.com>
Subject:  I-D ACTION:draft-ietf-opes-threats-00.txt
Date: Tue, 22 Oct 2002 11:40:53 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C279E1.67E24AE2"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C279E1.67E24AE2
Content-Type: text/plain


Hi, 

The IETF has fixed the confusion with the -00 and -01 of this draft that I
sent out this past sunday. This draft is the official -00. It is based on
the -01 draft the I have sent to the list.


Thanks

Abbie

------_=_NextPart_001_01C279E1.67E24AE2
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE> I-D ACTION:draft-ietf-opes-threats-00.txt</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>Hi, </FONT>
</P>

<P><FONT SIZE=3D2>The IETF has fixed the confusion with the -00 and -01 =
of this draft that I sent out this past sunday. This draft is the =
official -00. It is based on the -01 draft the I have sent to the =
list.</FONT></P>
<BR>

<P><FONT SIZE=3D2>Thanks</FONT>
</P>

<P><FONT SIZE=3D2>Abbie</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C279E1.67E24AE2--


From owner-ietf-openproxy@mail.imc.org  Wed Oct 23 10:42:54 2002
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07449
	for <opes-archive@ietf.org>; Wed, 23 Oct 2002 10:42:53 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g9NELHI17403
	for ietf-openproxy-bks; Wed, 23 Oct 2002 07:21:17 -0700 (PDT)
Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NELGW17397
	for <ietf-openproxy@imc.org>; Wed, 23 Oct 2002 07:21:16 -0700 (PDT)
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9NEL5p13337;
	Wed, 23 Oct 2002 10:21:05 -0400 (EDT)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <TLKC211Z>; Wed, 23 Oct 2002 10:21:06 -0400
Message-ID: <87609AFB433BD5118D5E0002A52CD75403EFDAFA@zcard0k6.ca.nortel.com>
From: "Abbie Barbir" <abbieb@nortelnetworks.com>
To: eburger@snowshore.com, OPES Group <ietf-openproxy@imc.org>
Subject: RE: Privacy Considerations (4.5)  in opes-authorization-00
Date: Wed, 23 Oct 2002 10:21:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C27A9F.6C813612"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C27A9F.6C813612
Content-Type: text/plain


eric,

it seems to me that you have already answered your question.

abbie

> -----Original Message-----
> From: Eric Burger [mailto:eburger@snowshore.com] 
> Sent: Monday, October 21, 2002 10:35 PM
> To: OPES Group
> Subject: Privacy Considerations (4.5) in opes-authorization-00
> 
> 
> 
> How can a user know that the PDP has user profiles so they 
> can limit the promulgation of their profile data?
> 
> 
> As pointed out in the thread on Authentication Requirements, 
> how does the PROTOCOL limit traffic data from being sent to 
> third parties?  How does the PROTOCOL know the difference 
> between a server run by the service provider and a server run 
> by a third party?
> 
> In the real world, the user and the service provider enter 
> into a trust agreement (outside of the protocol).  Part of 
> that agreement is that the service provider can or cannot let 
> third parties do work on their behalf. This, again, is 
> outside of the protocol.  POLICY dictates whether a service 
> provider may or may not send traffic data to third parties.
> 
> 

------_=_NextPart_001_01C27A9F.6C813612
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE>RE: Privacy Considerations (4.5)  in opes-authorization-00</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>eric,</FONT>
</P>

<P><FONT SIZE=2>it seems to me that you have already answered your question.</FONT>
</P>

<P><FONT SIZE=2>abbie</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Eric Burger [<A HREF="mailto:eburger@snowshore.com">mailto:eburger@snowshore.com</A>] </FONT>
<BR><FONT SIZE=2>&gt; Sent: Monday, October 21, 2002 10:35 PM</FONT>
<BR><FONT SIZE=2>&gt; To: OPES Group</FONT>
<BR><FONT SIZE=2>&gt; Subject: Privacy Considerations (4.5) in opes-authorization-00</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; How can a user know that the PDP has user profiles so they </FONT>
<BR><FONT SIZE=2>&gt; can limit the promulgation of their profile data?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; As pointed out in the thread on Authentication Requirements, </FONT>
<BR><FONT SIZE=2>&gt; how does the PROTOCOL limit traffic data from being sent to </FONT>
<BR><FONT SIZE=2>&gt; third parties?&nbsp; How does the PROTOCOL know the difference </FONT>
<BR><FONT SIZE=2>&gt; between a server run by the service provider and a server run </FONT>
<BR><FONT SIZE=2>&gt; by a third party?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; In the real world, the user and the service provider enter </FONT>
<BR><FONT SIZE=2>&gt; into a trust agreement (outside of the protocol).&nbsp; Part of </FONT>
<BR><FONT SIZE=2>&gt; that agreement is that the service provider can or cannot let </FONT>
<BR><FONT SIZE=2>&gt; third parties do work on their behalf. This, again, is </FONT>
<BR><FONT SIZE=2>&gt; outside of the protocol.&nbsp; POLICY dictates whether a service </FONT>
<BR><FONT SIZE=2>&gt; provider may or may not send traffic data to third parties.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C27A9F.6C813612--


From owner-ietf-openproxy@mail.imc.org  Wed Oct 23 10:44:58 2002
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07818
	for <opes-archive@ietf.org>; Wed, 23 Oct 2002 10:44:57 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g9NEDvM16297
	for ietf-openproxy-bks; Wed, 23 Oct 2002 07:13:57 -0700 (PDT)
Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NEDuW16290
	for <ietf-openproxy@imc.org>; Wed, 23 Oct 2002 07:13:56 -0700 (PDT)
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9NEDdp12443;
	Wed, 23 Oct 2002 10:13:39 -0400 (EDT)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <TLKC2D67>; Wed, 23 Oct 2002 10:13:40 -0400
Message-ID: <87609AFB433BD5118D5E0002A52CD75403EFDAC4@zcard0k6.ca.nortel.com>
From: "Abbie Barbir" <abbieb@nortelnetworks.com>
To: eburger@snowshore.com, OPES Group <ietf-openproxy@imc.org>
Subject: RE: Authentication Requirements in opes-authorization-00 (section
	 4.2)
Date: Wed, 23 Oct 2002 10:13:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C27A9E.62A8A0B8"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C27A9E.62A8A0B8
Content-Type: text/plain

see comments inline

abbie


> -----Original Message-----
> From: Eric Burger [mailto:eburger@snowshore.com] 
> Sent: Monday, October 21, 2002 10:35 PM
> To: OPES Group
> Subject: Authentication Requirements in opes-authorization-00 
> (section 4.2)
> 
> 
> 
> Section 4.2 states, "The service provider MUST keep a log of 
> all requests for OPES services".
> 
> Last I looked, the IETF is a protocol standards body, not a 
> legislative body.  Unless the *protocol* REQUIRES the service 
> provider to keep the log, this is an unenforceable 
> requirement.  I agree that we need to state our sentiment.  A 
> better place may be in the security section.
> 
-- agree.

> Likewise, "The trusted users must be authenticated before 
> being allowed to take actions" is a similar policy, not 
> protocol statement.  The good news is "must" is not 
> capitalized.  However, this statement again does not belong 
> in this section, and should be a SHOULD.
> 
-- agree
> The next paragraph is a place where we can have protocol 
> machinery: "The PEP's should be authenticated before they 
> receive policy rules".  If we care, then I would propose, 
> "Because of the sensitivity of user profiles, the PEP 
> Interface between the PEP and the PDP MUST use a secure 
> transport protocol."
> 
> 
-- I do see the point.
-- May be we should have a section that referes to good practice, which
include non-protocol related items.

abbie







------_=_NextPart_001_01C27A9E.62A8A0B8
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE>RE: Authentication Requirements in opes-authorization-00 (section 4.2)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>see comments inline</FONT>
</P>

<P><FONT SIZE=2>abbie</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Eric Burger [<A HREF="mailto:eburger@snowshore.com">mailto:eburger@snowshore.com</A>] </FONT>
<BR><FONT SIZE=2>&gt; Sent: Monday, October 21, 2002 10:35 PM</FONT>
<BR><FONT SIZE=2>&gt; To: OPES Group</FONT>
<BR><FONT SIZE=2>&gt; Subject: Authentication Requirements in opes-authorization-00 </FONT>
<BR><FONT SIZE=2>&gt; (section 4.2)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Section 4.2 states, &quot;The service provider MUST keep a log of </FONT>
<BR><FONT SIZE=2>&gt; all requests for OPES services&quot;.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Last I looked, the IETF is a protocol standards body, not a </FONT>
<BR><FONT SIZE=2>&gt; legislative body.&nbsp; Unless the *protocol* REQUIRES the service </FONT>
<BR><FONT SIZE=2>&gt; provider to keep the log, this is an unenforceable </FONT>
<BR><FONT SIZE=2>&gt; requirement.&nbsp; I agree that we need to state our sentiment.&nbsp; A </FONT>
<BR><FONT SIZE=2>&gt; better place may be in the security section.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>-- agree.</FONT>
</P>

<P><FONT SIZE=2>&gt; Likewise, &quot;The trusted users must be authenticated before </FONT>
<BR><FONT SIZE=2>&gt; being allowed to take actions&quot; is a similar policy, not </FONT>
<BR><FONT SIZE=2>&gt; protocol statement.&nbsp; The good news is &quot;must&quot; is not </FONT>
<BR><FONT SIZE=2>&gt; capitalized.&nbsp; However, this statement again does not belong </FONT>
<BR><FONT SIZE=2>&gt; in this section, and should be a SHOULD.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>-- agree</FONT>
<BR><FONT SIZE=2>&gt; The next paragraph is a place where we can have protocol </FONT>
<BR><FONT SIZE=2>&gt; machinery: &quot;The PEP's should be authenticated before they </FONT>
<BR><FONT SIZE=2>&gt; receive policy rules&quot;.&nbsp; If we care, then I would propose, </FONT>
<BR><FONT SIZE=2>&gt; &quot;Because of the sensitivity of user profiles, the PEP </FONT>
<BR><FONT SIZE=2>&gt; Interface between the PEP and the PDP MUST use a secure </FONT>
<BR><FONT SIZE=2>&gt; transport protocol.&quot;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>-- I do see the point.</FONT>
<BR><FONT SIZE=2>-- May be we should have a section that referes to good practice, which include non-protocol related items.</FONT>
</P>

<P><FONT SIZE=2>abbie</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C27A9E.62A8A0B8--


From owner-ietf-openproxy@mail.imc.org  Wed Oct 23 10:46:25 2002
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08087
	for <opes-archive@ietf.org>; Wed, 23 Oct 2002 10:46:24 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g9NEIxs17040
	for ietf-openproxy-bks; Wed, 23 Oct 2002 07:18:59 -0700 (PDT)
Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NEIwW17033
	for <ietf-openproxy@imc.org>; Wed, 23 Oct 2002 07:18:58 -0700 (PDT)
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9NEIlN03281;
	Wed, 23 Oct 2002 10:18:47 -0400 (EDT)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <TLKC21B0>; Wed, 23 Oct 2002 10:18:48 -0400
Message-ID: <87609AFB433BD5118D5E0002A52CD75403EFDAEA@zcard0k6.ca.nortel.com>
From: "Abbie Barbir" <abbieb@nortelnetworks.com>
To: eburger@snowshore.com, OPES Group <ietf-openproxy@imc.org>
Subject: RE: Unique Shared Secrets (4.4.2) in opes-authorization
Date: Wed, 23 Oct 2002 10:18:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C27A9F.19C41ACA"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C27A9F.19C41ACA
Content-Type: text/plain


eric,

The intend here is to secure the Hop-by-hop traffic. We can reaxime the
wording and the requirements.

-- This will be added as an action item for the -01 draft.

Abbie



> -----Original Message-----
> From: Eric Burger [mailto:eburger@snowshore.com] 
> Sent: Monday, October 21, 2002 10:35 PM
> To: OPES Group
> Subject: Unique Shared Secrets (4.4.2) in opes-authorization
> 
> 
> 
> Why must the shared secrets be unique for each requestor / 
> responder pair? Why do we care?  In fact, such a requirement 
> opens a security hole: I can guess someone else's key by 
> trying to enter keys until the "system" tells me I can't 
> because someone else has that key.
> 
> I would drop the bullet.
> 
> 

------_=_NextPart_001_01C27A9F.19C41ACA
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE>RE: Unique Shared Secrets (4.4.2) in opes-authorization</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>eric,</FONT>
</P>

<P><FONT SIZE=2>The intend here is to secure the Hop-by-hop traffic. We can reaxime the wording and the requirements.</FONT>
</P>

<P><FONT SIZE=2>-- This will be added as an action item for the -01 draft.</FONT>
</P>

<P><FONT SIZE=2>Abbie</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Eric Burger [<A HREF="mailto:eburger@snowshore.com">mailto:eburger@snowshore.com</A>] </FONT>
<BR><FONT SIZE=2>&gt; Sent: Monday, October 21, 2002 10:35 PM</FONT>
<BR><FONT SIZE=2>&gt; To: OPES Group</FONT>
<BR><FONT SIZE=2>&gt; Subject: Unique Shared Secrets (4.4.2) in opes-authorization</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Why must the shared secrets be unique for each requestor / </FONT>
<BR><FONT SIZE=2>&gt; responder pair? Why do we care?&nbsp; In fact, such a requirement </FONT>
<BR><FONT SIZE=2>&gt; opens a security hole: I can guess someone else's key by </FONT>
<BR><FONT SIZE=2>&gt; trying to enter keys until the &quot;system&quot; tells me I can't </FONT>
<BR><FONT SIZE=2>&gt; because someone else has that key.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I would drop the bullet.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C27A9F.19C41ACA--


From owner-ietf-openproxy@mail.imc.org  Wed Oct 23 11:43:45 2002
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19037
	for <opes-archive@ietf.org>; Wed, 23 Oct 2002 11:43:44 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g9NFEkr20847
	for ietf-openproxy-bks; Wed, 23 Oct 2002 08:14:46 -0700 (PDT)
Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NFEjW20841
	for <ietf-openproxy@imc.org>; Wed, 23 Oct 2002 08:14:46 -0700 (PDT)
Received: from oskar3 ([24.218.184.133]) by rwcrmhc53.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20021023151442.YWLE8248.rwcrmhc53.attbi.com@oskar3>
          for <ietf-openproxy@imc.org>; Wed, 23 Oct 2002 15:14:42 +0000
From: "Oskar Batuner" <batuner@attbi.com>
To: "OPES Group" <ietf-openproxy@imc.org>
Subject: RE: Authentication Requirements in opes-authorization-00 (section 4.2)
Date: Wed, 23 Oct 2002 11:14:43 -0400
Message-ID: <JMEPINMLHPLMNBBANKEHKEBDCFAA.batuner@attbi.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <BEEMKJGAMKLMAIKEECBAKEHIDCAA.eburger@snowshore.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


Eric, technically you right - if we are looking only at transport
protocols many things in this draft are not relevant. But
essentially OPES (as well as WEBI and CDN) works on "overlay
network" - the architecture describes system structure built
above application level protocol. This structure sets requirements
for protocols and policies. In this sense one might look at
policies as a very high level protocols that control
communication of certain application level information.

IETF often ventures beyond protocol level considerations. A good
example is RFC 3238 - IAB Considerations for OPES. Out of all
considerations listed in the summary only one - 2.2, IP-layer
addressing - is talking about protocol level requirements, and
even this one is based on policy considerations that are
not dictated by the data transfer needs.

Again, I agree that many OPES drafts do have some inconsistencies
that are due to the fact that each of these drafts deals with
variety of protocol levels. Comments like this one may help
to improve them - but we should always keep in mind that this
group is working not on protocol, but on multilevel
infrastructure.

Oskar


> -----Original Message-----
> From: owner-ietf-openproxy@mail.imc.org
> [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Eric Burger
> Sent: Monday, October 21, 2002 10:35 PM
> To: OPES Group
> Subject: Authentication Requirements in opes-authorization-00 (section
> 4.2)
>
>
>
> Section 4.2 states, "The service provider MUST keep a log of all requests
> for OPES services".
>
> Last I looked, the IETF is a protocol standards body, not a legislative
> body.  Unless the *protocol* REQUIRES the service provider to
> keep the log,
> this is an unenforceable requirement.  I agree that we need to state our
> sentiment.  A better place may be in the security section.
>
> Likewise, "The trusted users must be authenticated before being allowed to
> take actions" is a similar policy, not protocol statement.  The
> good news is
> "must" is not capitalized.  However, this statement again does
> not belong in
> this section, and should be a SHOULD.
>
> The next paragraph is a place where we can have protocol machinery: "The
> PEP's should be authenticated before they receive policy rules".  If we
> care, then I would propose, "Because of the sensitivity of user profiles,
> the PEP Interface between the PEP and the PDP MUST use a secure transport
> protocol."



From owner-ietf-openproxy@mail.imc.org  Fri Oct 25 14:45:26 2002
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06317
	for <opes-archive@ietf.org>; Fri, 25 Oct 2002 14:45:24 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g9PI5Wg17300
	for ietf-openproxy-bks; Fri, 25 Oct 2002 11:05:32 -0700 (PDT)
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g9PI5UW17295
	for <ietf-openproxy@imc.org>; Fri, 25 Oct 2002 11:05:30 -0700 (PDT)
Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9PI5dv11286
	for <ietf-openproxy@imc.org>; Fri, 25 Oct 2002 13:05:39 -0500 (CDT)
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <VDYBB2FR>; Fri, 25 Oct 2002 11:05:24 -0700
Message-ID: <7B802811BE77D51189910002A55CFD2C045F075D@zsc3c032.us.nortel.com>
From: "Reinaldo Penno" <rpenno@nortelnetworks.com>
To: OPES Group <ietf-openproxy@imc.org>
Subject: Some comments on draft-ietf-opes-threats-00
Date: Fri, 25 Oct 2002 11:05:25 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C27C51.17D7A980"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C27C51.17D7A980
Content-Type: text/plain;
	charset="iso-8859-1"

a)I propose a little bit of rewording on this paragraph

   "These threats affect the quality and integrity of data that the
   applications either produce or consume.  On the other hand, the
   security risks can also be categorized into trust within the system
   (i.e.  OPES service providers) and protection of the system from
   threats imposed by outsiders such as hackers and attackers.  Insiders
   are those parties that are part of the OPES system.  Outsiders are
   those entities that are not participating in the OPES system."



   These threats affect the quality and integrity of data that the
   applications either produce or consume.  -->On the other hand, the
   security risks can also be categorized into those originating  
   inside the system (i.e.  OPES service providers) and those 
   originated by outsiders such as hackers and attackers<--  Insiders
   are those parties that are part of the OPES system.  Outsiders are
   those entities that are not participating in the OPES system.

With the rewording the last 3 sentences  flow better since the inside and
outside 
words are used in the sentence to categorize the threats.

b) Correct if I'm wrong here but it seems to me the (original?) idea of this
document was to document the *additional/specific* security threats the
addtion of an OPES impose. The document as it stands today basically lists
more or less all attacks known to man. 

Take eavesdropping for example (2.1.4). The additional risk IMO is only when
somebody breaks into the OPES system and use that to eavesdrop the traffic.
Otherwise eavesdropping a network was and is always possible. 

Other examples such as a malign device impersonating a callout server seems
a little bit far-fetched since I would assume mutual authentication and the
like would make this a configuration error instead of a threat...oh
well...everything is posssible.

c) "A serious problem is posed by the very fact that the OPES
   architecture is based on widely adopted protocols (HTTP is used as an
   example)."

Is this really a problem? It seems to me it would be problem is it is
(widely deployed + not mature and/or not open), such as some P2P protocols.
Widely deployed alone does not make it a security problem.


------_=_NextPart_001_01C27C51.17D7A980
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>Some comments on draft-ietf-opes-threats-00</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>a)I propose a little bit of rewording on this =
paragraph</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; &quot;These threats affect the quality =
and integrity of data that the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; applications either produce or =
consume.&nbsp; On the other hand, the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; security risks can also be categorized =
into trust within the system</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; (i.e.&nbsp; OPES service providers) and =
protection of the system from</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; threats imposed by outsiders such as =
hackers and attackers.&nbsp; Insiders</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; are those parties that are part of the =
OPES system.&nbsp; Outsiders are</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; those entities that are not =
participating in the OPES system.&quot;</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&nbsp;&nbsp; These threats affect the quality and =
integrity of data that the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; applications either produce or =
consume.&nbsp; --&gt;On the other hand, the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; security risks can also be categorized =
into those originating&nbsp; </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; inside the system (i.e.&nbsp; OPES =
service providers) and those </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; originated by outsiders such as hackers =
and attackers&lt;--&nbsp; Insiders</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; are those parties that are part of the =
OPES system.&nbsp; Outsiders are</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; those entities that are not =
participating in the OPES system.</FONT>
</P>

<P><FONT SIZE=3D2>With the rewording the last 3 sentences&nbsp; flow =
better since the inside and outside </FONT>
<BR><FONT SIZE=3D2>words are used in the sentence to categorize the =
threats.</FONT>
</P>

<P><FONT SIZE=3D2>b) Correct if I'm wrong here but it seems to me the =
(original?) idea of this document was to document the =
*additional/specific* security threats the addtion of an OPES impose. =
The document as it stands today basically lists more or less all =
attacks known to man. </FONT></P>

<P><FONT SIZE=3D2>Take eavesdropping for example (2.1.4). The =
additional risk IMO is only when somebody breaks into the OPES system =
and use that to eavesdrop the traffic. Otherwise eavesdropping a =
network was and is always possible. </FONT></P>

<P><FONT SIZE=3D2>Other examples such as a malign device impersonating =
a callout server seems a little bit far-fetched since I would assume =
mutual authentication and the like would make this a configuration =
error instead of a threat...oh well...everything is =
posssible.</FONT></P>

<P><FONT SIZE=3D2>c) &quot;A serious problem is posed by the very fact =
that the OPES</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; architecture is based on widely adopted =
protocols (HTTP is used as an</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; example).&quot;</FONT>
</P>

<P><FONT SIZE=3D2>Is this really a problem? It seems to me it would be =
problem is it is (widely deployed + not mature and/or not open), such =
as some P2P protocols. Widely deployed alone does not make it a =
security problem.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C27C51.17D7A980--


From owner-ietf-openproxy@mail.imc.org  Fri Oct 25 17:26:07 2002
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12660
	for <opes-archive@ietf.org>; Fri, 25 Oct 2002 17:26:06 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g9PL48V28041
	for ietf-openproxy-bks; Fri, 25 Oct 2002 14:04:08 -0700 (PDT)
Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g9PL44W28037
	for <ietf-openproxy@imc.org>; Fri, 25 Oct 2002 14:04:04 -0700 (PDT)
Received: from oskar3 ([24.218.184.133]) by rwcrmhc53.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20021025210357.KZJI9096.rwcrmhc53.attbi.com@oskar3>;
          Fri, 25 Oct 2002 21:03:57 +0000
From: "Oskar Batuner" <batuner@attbi.com>
To: "Reinaldo Penno" <rpenno@nortelnetworks.com>,
        "OPES Group" <ietf-openproxy@imc.org>
Subject: RE: Some comments on draft-ietf-opes-threats-00
Date: Fri, 25 Oct 2002 17:03:59 -0400
Message-ID: <JMEPINMLHPLMNBBANKEHEECECFAA.batuner@attbi.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <7B802811BE77D51189910002A55CFD2C045F075D@zsc3c032.us.nortel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit



-----Original Message-----
>From: owner-ietf-openproxy@mail.imc.org
[mailto:owner-ietf-openproxy@mail.imc.org]On
>Behalf Of Reinaldo Penno
>Sent: Friday, October 25, 2002 2:05 PM
>To: OPES Group
>Subject: Some comments on draft-ietf-opes-threats-00
>
>
>a)  I propose a little bit of rewording on this paragraph
>   "These threats affect the quality and integrity of data that the
>   applications either produce or consume.  On the other hand, the
>   security risks can also be categorized into trust within the system
>   (i.e.  OPES service providers) and protection of the system from
>   threats imposed by outsiders such as hackers and attackers.  Insiders
>   are those parties that are part of the OPES system.  Outsiders are
>   those entities that are not participating in the OPES system."
>
>
>
>   These threats affect the quality and integrity of data that the
>   applications either produce or consume.  -->On the other hand, the
>   security risks can also be categorized into those originating
>   inside the system (i.e.  OPES service providers) and those
>   originated by outsiders such as hackers and attackers<--  Insiders
>   are those parties that are part of the OPES system.  Outsiders are
>   those entities that are not participating in the OPES system.
>With the rewording the last 3 sentences  flow better since the inside and
outside
>words are used in the sentence to categorize the threats.

Looks good, thanks.

>b) Correct if I'm wrong here but it seems to me the (original?)
>idea of this document was to document the *additional/specific*
>security threats the addition of an OPES impose. The document as
>it stands today basically lists more or less all attacks known
>to man.
>Take eavesdropping for example (2.1.4). The additional risk IMO
>is only when somebody breaks into the OPES system and use that to
>eavesdrop the traffic. Otherwise eavesdropping a network was and
>is always possible.
>Other examples such as a malign device impersonating a callout
>server seems a little bit far-fetched since I would assume mutual
>authentication and the like would make this a configuration error
>instead of a threat...oh well...everything is possible.

The problem you are pointing to does exist, but I hope it is
limited to a few subsections in section 2, namely 2.1.1 - 2.1.5.

It's unfortunate if these subsections have a negative impact on the
reader's attitude as they come before description of specific
OPES-related threats. Maybe these subsections should be compressed
into one that emphasizes OPES-related aspect of these generic
threats.

>c) "A serious problem is posed by the very fact that the OPES
>   architecture is based on widely adopted protocols (HTTP is used as an
>   example)."
>Is this really a problem? It seems to me it would be problem is it is
>(widely deployed + not mature and/or not open), such as some P2P protocols.
>Widely deployed alone does not make it a security problem.

The problem is posed by the fact that we intend to use not only the
HTTP but also the existing user agents (browsers). This seriously
limits system abilities to mitigate threats by adding protocol
extensions - like special message structure, tracing/notification
headers, signatures that are transparent to non-OPES aware
counterparts and other similar things.

Existing browsers are not aware of such additions and
will simply ignore any discrepancies caused by security
violations.

Oskar



From owner-ietf-openproxy@mail.imc.org  Sat Oct 26 14:17:45 2002
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10159
	for <opes-archive@ietf.org>; Sat, 26 Oct 2002 14:17:44 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g9QHq5C03984
	for ietf-openproxy-bks; Sat, 26 Oct 2002 10:52:05 -0700 (PDT)
Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g9QHq4W03980
	for <ietf-openproxy@imc.org>; Sat, 26 Oct 2002 10:52:04 -0700 (PDT)
Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215])
 by mtaout05.icomcast.net
 (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug  5 2002))
 with ESMTP id <0H4L004HSOAKKV@mtaout05.icomcast.net> for
 ietf-openproxy@imc.org; Sat, 26 Oct 2002 13:51:56 -0400 (EDT)
Date: Sat, 26 Oct 2002 13:52:00 -0400
From: Markus Hofmann <markus@mhof.com>
Subject: Re: Authentication Requirements in opes-authorization-00 (section 4.2)
In-reply-to: <BEEMKJGAMKLMAIKEECBAKEHIDCAA.eburger@snowshore.com>
To: eburger@snowshore.com
Cc: OPES Group <ietf-openproxy@imc.org>
Message-id: <3DBAD640.3060309@mhof.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b)
 Gecko/20021016
References: <BEEMKJGAMKLMAIKEECBAKEHIDCAA.eburger@snowshore.com>
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7BIT


Eric Burger wrote:

> The next paragraph is a place where we can have protocol machinery:
> "The PEP's should be authenticated before they receive policy
> rules".  If we care, then I would propose, "Because of the
> sensitivity of user profiles, the PEP Interface between the PEP and
> the PDP MUST use a secure transport protocol."

How about phrasing it more like "Because of the sensitivity of user 
profiles, the PEP Interface between the PEP and the PDP MUST use a 
secured communication channel" rather than requiring a "...secure 
transport protocol...". Communication between PEP and PDP can be 
secured in different ways, and does not always require a secure 
*transport protocol*. (Assume, for example, that PDP and PEP are in 
the same administrative domain, which is protected via firewalls or so...)

-Markus



From owner-ietf-openproxy@mail.imc.org  Sat Oct 26 14:31:28 2002
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10333
	for <opes-archive@ietf.org>; Sat, 26 Oct 2002 14:31:27 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g9QHwsv04359
	for ietf-openproxy-bks; Sat, 26 Oct 2002 10:58:54 -0700 (PDT)
Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g9QHwrW04353
	for <ietf-openproxy@imc.org>; Sat, 26 Oct 2002 10:58:53 -0700 (PDT)
Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215])
 by mtaout03.icomcast.net
 (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug  5 2002))
 with ESMTP id <0H4L00ISGOLZQ0@mtaout03.icomcast.net> for
 ietf-openproxy@imc.org; Sat, 26 Oct 2002 13:58:48 -0400 (EDT)
Date: Sat, 26 Oct 2002 13:58:47 -0400
From: Markus Hofmann <markus@mhof.com>
Subject: Re: Some comments on draft-ietf-opes-threats-00
In-reply-to: <JMEPINMLHPLMNBBANKEHEECECFAA.batuner@attbi.com>
To: Oskar Batuner <batuner@attbi.com>
Cc: Reinaldo Penno <rpenno@nortelnetworks.com>,
        OPES Group <ietf-openproxy@imc.org>
Message-id: <3DBAD7D7.2030900@mhof.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b)
 Gecko/20021016
References: <JMEPINMLHPLMNBBANKEHEECECFAA.batuner@attbi.com>
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7BIT


Oskar Batuner wrote:

>> b) Correct if I'm wrong here but it seems to me the (original?) 
>> idea of this document was to document the *additional/specific* 
>> security threats the addition of an OPES impose. The document as 
>> it stands today basically lists more or less all attacks known to
>> man. [...]
> 
> The problem you are pointing to does exist, but I hope it is 
> limited to a few subsections in section 2, namely 2.1.1 - 2.1.5.

I agree with both, the problem exists, in particular in Section 2.1. 
This section should be structured in a way that it talks only about 
network level threats *introduced by the new OPES components*, rather 
then explaining tnetwork level threats in general.

Example in Section 2.1.4: It isn't necessary to explain what 
eavesdropping is, and it isn't necessary to explain that this is an 
issue for transmitting information between a client and a server. But 
it is important to point out that the introduction of OPES processors 
and callout servers opens new possibilities for eavesdropping, namely 
on the link between OPES processor and callout server. This is a *new* 
threat compared to non-OPES environments, and has direct implications 
on the OPES requirements. The section - and the document in general - 
should focus on threats introduced by the new OPES elements, and 
explicitely spell those out.

I think this can easily be fixed.

-Markus



From owner-ietf-openproxy@mail.imc.org  Mon Oct 28 10:36:00 2002
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14517
	for <opes-archive@ietf.org>; Mon, 28 Oct 2002 10:35:59 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g9SF55S00648
	for ietf-openproxy-bks; Mon, 28 Oct 2002 07:05:05 -0800 (PST)
Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SF54W00642
	for <ietf-openproxy@imc.org>; Mon, 28 Oct 2002 07:05:04 -0800 (PST)
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9SF4ku20457;
	Mon, 28 Oct 2002 10:04:46 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <TLKCK2WK>; Mon, 28 Oct 2002 10:04:46 -0500
Message-ID: <87609AFB433BD5118D5E0002A52CD75403F6D8F6@zcard0k6.ca.nortel.com>
From: "Abbie Barbir" <abbieb@nortelnetworks.com>
To: Markus Hofmann <markus@mhof.com>, Oskar Batuner <batuner@attbi.com>
Cc: "Reinaldo Penno" <rpenno@nortelnetworks.com>,
        OPES Group <ietf-openproxy@imc.org>
Subject: RE: Some comments on draft-ietf-opes-threats-00
Date: Mon, 28 Oct 2002 10:04:40 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C27E93.572A1C28"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C27E93.572A1C28
Content-Type: text/plain

+1

abbie


> -----Original Message-----
> From: Markus Hofmann [mailto:markus@mhof.com] 
> Sent: Saturday, October 26, 2002 1:59 PM
> To: Oskar Batuner
> Cc: Penno, Reinaldo [BL60:0430:EXCH]; OPES Group
> Subject: Re: Some comments on draft-ietf-opes-threats-00
> 
> 
> 
> Oskar Batuner wrote:
> 
> >> b) Correct if I'm wrong here but it seems to me the (original?)
> >> idea of this document was to document the *additional/specific* 
> >> security threats the addition of an OPES impose. The document as 
> >> it stands today basically lists more or less all attacks known to
> >> man. [...]
> > 
> > The problem you are pointing to does exist, but I hope it is
> > limited to a few subsections in section 2, namely 2.1.1 - 2.1.5.
> 
> I agree with both, the problem exists, in particular in Section 2.1. 
> This section should be structured in a way that it talks only about 
> network level threats *introduced by the new OPES components*, rather 
> then explaining tnetwork level threats in general.
> 
> Example in Section 2.1.4: It isn't necessary to explain what 
> eavesdropping is, and it isn't necessary to explain that this is an 
> issue for transmitting information between a client and a server. But 
> it is important to point out that the introduction of OPES processors 
> and callout servers opens new possibilities for eavesdropping, namely 
> on the link between OPES processor and callout server. This 
> is a *new* 
> threat compared to non-OPES environments, and has direct implications 
> on the OPES requirements. The section - and the document in general - 
> should focus on threats introduced by the new OPES elements, and 
> explicitely spell those out.
> 
> I think this can easily be fixed.
> 
> -Markus
> 
> 

------_=_NextPart_001_01C27E93.572A1C28
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE>RE: Some comments on draft-ietf-opes-threats-00</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>+1</FONT>
</P>

<P><FONT SIZE=2>abbie</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Markus Hofmann [<A HREF="mailto:markus@mhof.com">mailto:markus@mhof.com</A>] </FONT>
<BR><FONT SIZE=2>&gt; Sent: Saturday, October 26, 2002 1:59 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Oskar Batuner</FONT>
<BR><FONT SIZE=2>&gt; Cc: Penno, Reinaldo [BL60:0430:EXCH]; OPES Group</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: Some comments on draft-ietf-opes-threats-00</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Oskar Batuner wrote:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; b) Correct if I'm wrong here but it seems to me the (original?)</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; idea of this document was to document the *additional/specific* </FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; security threats the addition of an OPES impose. The document as </FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; it stands today basically lists more or less all attacks known to</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; man. [...]</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; The problem you are pointing to does exist, but I hope it is</FONT>
<BR><FONT SIZE=2>&gt; &gt; limited to a few subsections in section 2, namely 2.1.1 - 2.1.5.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I agree with both, the problem exists, in particular in Section 2.1. </FONT>
<BR><FONT SIZE=2>&gt; This section should be structured in a way that it talks only about </FONT>
<BR><FONT SIZE=2>&gt; network level threats *introduced by the new OPES components*, rather </FONT>
<BR><FONT SIZE=2>&gt; then explaining tnetwork level threats in general.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Example in Section 2.1.4: It isn't necessary to explain what </FONT>
<BR><FONT SIZE=2>&gt; eavesdropping is, and it isn't necessary to explain that this is an </FONT>
<BR><FONT SIZE=2>&gt; issue for transmitting information between a client and a server. But </FONT>
<BR><FONT SIZE=2>&gt; it is important to point out that the introduction of OPES processors </FONT>
<BR><FONT SIZE=2>&gt; and callout servers opens new possibilities for eavesdropping, namely </FONT>
<BR><FONT SIZE=2>&gt; on the link between OPES processor and callout server. This </FONT>
<BR><FONT SIZE=2>&gt; is a *new* </FONT>
<BR><FONT SIZE=2>&gt; threat compared to non-OPES environments, and has direct implications </FONT>
<BR><FONT SIZE=2>&gt; on the OPES requirements. The section - and the document in general - </FONT>
<BR><FONT SIZE=2>&gt; should focus on threats introduced by the new OPES elements, and </FONT>
<BR><FONT SIZE=2>&gt; explicitely spell those out.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I think this can easily be fixed.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -Markus</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C27E93.572A1C28--


From owner-ietf-openproxy@mail.imc.org  Mon Oct 28 16:46:29 2002
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01210
	for <opes-archive@ietf.org>; Mon, 28 Oct 2002 16:46:28 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g9SL7PJ00735
	for ietf-openproxy-bks; Mon, 28 Oct 2002 13:07:25 -0800 (PST)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SL7PW00731
	for <ietf-openproxy@imc.org>; Mon, 28 Oct 2002 13:07:25 -0800 (PST)
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9SL8IX13179
	for <ietf-openproxy@imc.org>; Mon, 28 Oct 2002 15:08:18 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5e37f3b8c2ac12f257079@davir04nok.americas.nokia.com>;
 Mon, 28 Oct 2002 15:07:25 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Mon, 28 Oct 2002 13:07:24 -0800
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C27EC5.F9422280"
Subject: RE: Unique Shared Secrets (4.4.2) in opes-authorization
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Mon, 28 Oct 2002 16:07:07 -0500
Message-ID: <DC504E9C3384054C8506D3E6BB0124600BAD79@bsebe001.americas.nokia.com>
Thread-Topic: Unique Shared Secrets (4.4.2) in opes-authorization
Thread-Index: AcJ6oiYsTQy8Td6XQhqb9kKLULBBAwEIc5OQ
From: <bindignavile.srinivas@nokia.com>
To: <abbieb@nortelnetworks.com>, <eburger@snowshore.com>,
        <ietf-openproxy@imc.org>
X-OriginalArrivalTime: 28 Oct 2002 21:07:24.0945 (UTC) FILETIME=[03A34010:01C27EC6]
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This is a multi-part message in MIME format.

------_=_NextPart_001_01C27EC5.F9422280
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
I had a look at the opes-authorization draft again, and I too was not =
really convinced of the need for "unique" shared secrets for each =
requestor/responder pair. The only way I can see for the integrity and =
confidentiality of OPES data (application) flow to be compromised is:
=20
1. Two different data streams (with different "content consumers" and =
same or different "content providers") share the same OPES device.
2. One of the two CC's is malicious.
3. In this event, if the shared secrets for each requestor/responder =
pair are not unique, then the integrity and confidentiality of OPES data =
could be compromised.
=20
However, if all the OPES CC's can be trusted, then uniqueness is not =
needed, IMHO!
=20
-Srini

-----Original Message-----
From: ext Abbie Barbir [mailto:abbieb@nortelnetworks.com]
Sent: Wednesday, October 23, 2002 10:19 AM
To: eburger@snowshore.com; OPES Group
Subject: RE: Unique Shared Secrets (4.4.2) in opes-authorization




eric,=20

The intend here is to secure the Hop-by-hop traffic. We can reaxime the =
wording and the requirements.=20

-- This will be added as an action item for the -01 draft.=20

Abbie=20



> -----Original Message-----=20
> From: Eric Burger [ mailto:eburger@snowshore.com]=20
> Sent: Monday, October 21, 2002 10:35 PM=20
> To: OPES Group=20
> Subject: Unique Shared Secrets (4.4.2) in opes-authorization=20
>=20
>=20
>=20
> Why must the shared secrets be unique for each requestor /=20
> responder pair? Why do we care?  In fact, such a requirement=20
> opens a security hole: I can guess someone else's key by=20
> trying to enter keys until the "system" tells me I can't=20
> because someone else has that key.=20
>=20
> I would drop the bullet.=20
>=20
>=20


------_=_NextPart_001_01C27EC5.F9422280
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>RE: Unique Shared Secrets (4.4.2) in opes-authorization</TITLE>

<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D755405220-28102002><FONT face=3DArial color=3D#0000ff =

size=3D2>Hi,</FONT></SPAN></DIV>
<DIV><SPAN class=3D755405220-28102002><FONT face=3DArial color=3D#0000ff =
size=3D2>I had=20
a look at the opes-authorization draft again, and I too was not really =
convinced=20
of the need for "unique" shared secrets&nbsp;for each =
requestor/responder pair.=20
The only way I can see for the integrity and confidentiality of OPES =
data=20
(application) flow to be compromised is:</FONT></SPAN></DIV>
<DIV><SPAN class=3D755405220-28102002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D755405220-28102002><FONT face=3DArial color=3D#0000ff =
size=3D2>1. Two=20
different data streams (with different "content consumers" and same or =
different=20
"content providers") share the same OPES device.</FONT></SPAN></DIV>
<DIV><SPAN class=3D755405220-28102002><FONT face=3DArial color=3D#0000ff =
size=3D2>2. One=20
of the two CC's is malicious.</FONT></SPAN></DIV>
<DIV><SPAN class=3D755405220-28102002><FONT face=3DArial color=3D#0000ff =
size=3D2>3. In=20
this event, if the shared secrets for each requestor/responder =
pair&nbsp;are not=20
unique, then the integrity and confidentiality of OPES data could be=20
compromised.</FONT></SPAN></DIV>
<DIV><SPAN class=3D755405220-28102002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D755405220-28102002><FONT face=3DArial color=3D#0000ff =

size=3D2>However, if all the OPES CC's can be trusted, then uniqueness =
is not=20
needed, IMHO!</FONT></SPAN></DIV>
<DIV><SPAN class=3D755405220-28102002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D755405220-28102002><FONT face=3DArial color=3D#0000ff =

size=3D2>-Srini</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> ext Abbie Barbir=20
  [mailto:abbieb@nortelnetworks.com]<BR><B>Sent:</B> Wednesday, October =
23, 2002=20
  10:19 AM<BR><B>To:</B> eburger@snowshore.com; OPES =
Group<BR><B>Subject:</B>=20
  RE: Unique Shared Secrets (4.4.2) in=20
  opes-authorization<BR><BR></FONT></DIV><BR>
  <P><FONT size=3D2>eric,</FONT> </P>
  <P><FONT size=3D2>The intend here is to secure the Hop-by-hop traffic. =
We can=20
  reaxime the wording and the requirements.</FONT> </P>
  <P><FONT size=3D2>-- This will be added as an action item for the -01=20
  draft.</FONT> </P>
  <P><FONT size=3D2>Abbie</FONT> </P><BR><BR>
  <P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;=20
  From: Eric Burger [<A=20
  =
href=3D"mailto:eburger@snowshore.com">mailto:eburger@snowshore.com</A>]=20
  </FONT><BR><FONT size=3D2>&gt; Sent: Monday, October 21, 2002 10:35 =
PM</FONT>=20
  <BR><FONT size=3D2>&gt; To: OPES Group</FONT> <BR><FONT size=3D2>&gt; =
Subject:=20
  Unique Shared Secrets (4.4.2) in opes-authorization</FONT> <BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; Why must the shared secrets be unique =
for each=20
  requestor / </FONT><BR><FONT size=3D2>&gt; responder pair? Why do we =
care?&nbsp;=20
  In fact, such a requirement </FONT><BR><FONT size=3D2>&gt; opens a =
security=20
  hole: I can guess someone else's key by </FONT><BR><FONT size=3D2>&gt; =
trying to=20
  enter keys until the "system" tells me I can't </FONT><BR><FONT =
size=3D2>&gt;=20
  because someone else has that key.</FONT> <BR><FONT size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; I would drop the bullet.</FONT> =
<BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
</FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C27EC5.F9422280--


From owner-ietf-openproxy@mail.imc.org  Mon Oct 28 17:43:00 2002
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02593
	for <opes-archive@ietf.org>; Mon, 28 Oct 2002 17:42:59 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g9SMBjR02941
	for ietf-openproxy-bks; Mon, 28 Oct 2002 14:11:45 -0800 (PST)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SMBhW02932
	for <ietf-openproxy@imc.org>; Mon, 28 Oct 2002 14:11:43 -0800 (PST)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9SMCbX23991
	for <ietf-openproxy@imc.org>; Mon, 28 Oct 2002 16:12:37 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5e382e99b1ac12f255079@davir02nok.americas.nokia.com>;
 Mon, 28 Oct 2002 16:11:43 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Mon, 28 Oct 2002 16:11:43 -0600
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C27ECE.FEF56524"
Subject: RE: Unique Shared Secrets (4.4.2) in opes-authorization
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Mon, 28 Oct 2002 17:11:42 -0500
Message-ID: <DC504E9C3384054C8506D3E6BB0124600BAD7B@bsebe001.americas.nokia.com>
Thread-Topic: Unique Shared Secrets (4.4.2) in opes-authorization
Thread-Index: AcJ6oiYsTQy8Td6XQhqb9kKLULBBAwEIc5OQAAKQ4lA=
From: <bindignavile.srinivas@nokia.com>
To: <bindignavile.srinivas@nokia.com>, <abbieb@nortelnetworks.com>,
        <eburger@snowshore.com>, <ietf-openproxy@imc.org>
X-OriginalArrivalTime: 28 Oct 2002 22:11:43.0820 (UTC) FILETIME=[FFB4D8C0:01C27ECE]
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This is a multi-part message in MIME format.

------_=_NextPart_001_01C27ECE.FEF56524
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
I forgot to include a few words in my previous response on this issue! =
When I wrote "The only way I can see for the integrity and =
confidentiality of OPES data (application) flow to be compromised ", =
what I meant was that, if the shared keys are not unique, then the OPES =
data flow integrity could be compromised by the suggested technique.
=20
-Srini
=20

-----Original Message-----
From: ext [mailto:bindignavile.srinivas@nokia.com]
Sent: Monday, October 28, 2002 4:07 PM
To: abbieb@nortelnetworks.com; eburger@snowshore.com; =
ietf-openproxy@imc.org
Subject: RE: Unique Shared Secrets (4.4.2) in opes-authorization


Hi,
I had a look at the opes-authorization draft again, and I too was not =
really convinced of the need for "unique" shared secrets for each =
requestor/responder pair. The only way I can see for the integrity and =
confidentiality of OPES data (application) flow to be compromised is:
=20
1. Two different data streams (with different "content consumers" and =
same or different "content providers") share the same OPES device.
2. One of the two CC's is malicious.
3. In this event, if the shared secrets for each requestor/responder =
pair are not unique, then the integrity and confidentiality of OPES data =
could be compromised.
=20
However, if all the OPES CC's can be trusted, then uniqueness is not =
needed, IMHO!
=20
-Srini

-----Original Message-----
From: ext Abbie Barbir [mailto:abbieb@nortelnetworks.com]
Sent: Wednesday, October 23, 2002 10:19 AM
To: eburger@snowshore.com; OPES Group
Subject: RE: Unique Shared Secrets (4.4.2) in opes-authorization




eric,=20

The intend here is to secure the Hop-by-hop traffic. We can reaxime the =
wording and the requirements.=20

-- This will be added as an action item for the -01 draft.=20

Abbie=20



> -----Original Message-----=20
> From: Eric Burger [ mailto:eburger@snowshore.com]=20
> Sent: Monday, October 21, 2002 10:35 PM=20
> To: OPES Group=20
> Subject: Unique Shared Secrets (4.4.2) in opes-authorization=20
>=20
>=20
>=20
> Why must the shared secrets be unique for each requestor /=20
> responder pair? Why do we care?  In fact, such a requirement=20
> opens a security hole: I can guess someone else's key by=20
> trying to enter keys until the "system" tells me I can't=20
> because someone else has that key.=20
>=20
> I would drop the bullet.=20
>=20
>=20


------_=_NextPart_001_01C27ECE.FEF56524
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>RE: Unique Shared Secrets (4.4.2) in opes-authorization</TITLE>

<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D074090622-28102002><FONT face=3DArial color=3D#0000ff =

size=3D2>Hi,</FONT></SPAN></DIV>
<DIV><SPAN class=3D074090622-28102002><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
forgot to include a few words in my previous response&nbsp;on this =
issue! When I=20
wrote "The only way I can see for the integrity and confidentiality of =
OPES data=20
(application) flow to be compromised ", what I meant was that, if the =
shared=20
keys are not unique, then the OPES data flow integrity could be =
compromised by=20
the suggested technique.</FONT></SPAN></DIV>
<DIV><SPAN class=3D074090622-28102002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D074090622-28102002><FONT face=3DArial color=3D#0000ff =

size=3D2>-Srini</FONT></SPAN></DIV>
<DIV><SPAN class=3D074090622-28102002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> ext=20
  [mailto:bindignavile.srinivas@nokia.com]<BR><B>Sent:</B> Monday, =
October 28,=20
  2002 4:07 PM<BR><B>To:</B> abbieb@nortelnetworks.com; =
eburger@snowshore.com;=20
  ietf-openproxy@imc.org<BR><B>Subject:</B> RE: Unique Shared Secrets =
(4.4.2) in=20
  opes-authorization<BR><BR></FONT></DIV>
  <DIV><SPAN class=3D755405220-28102002><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Hi,</FONT></SPAN></DIV>
  <DIV><SPAN class=3D755405220-28102002><FONT face=3DArial =
color=3D#0000ff size=3D2>I=20
  had a look at the opes-authorization draft again, and I too was not =
really=20
  convinced of the need for "unique" shared secrets&nbsp;for each=20
  requestor/responder pair. The only way I can see for the integrity and =

  confidentiality of OPES data (application) flow to be compromised=20
  is:</FONT></SPAN></DIV>
  <DIV><SPAN class=3D755405220-28102002><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D755405220-28102002><FONT face=3DArial =
color=3D#0000ff size=3D2>1.=20
  Two different data streams (with different "content consumers" and =
same or=20
  different "content providers") share the same OPES =
device.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D755405220-28102002><FONT face=3DArial =
color=3D#0000ff size=3D2>2.=20
  One of the two CC's is malicious.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D755405220-28102002><FONT face=3DArial =
color=3D#0000ff size=3D2>3.=20
  In this event, if the shared secrets for each requestor/responder=20
  pair&nbsp;are not unique, then the integrity and confidentiality of =
OPES data=20
  could be compromised.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D755405220-28102002><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D755405220-28102002><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>However, if all the OPES CC's can be trusted, then uniqueness =
is not=20
  needed, IMHO!</FONT></SPAN></DIV>
  <DIV><SPAN class=3D755405220-28102002><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D755405220-28102002><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>-Srini</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> ext Abbie Barbir =

    [mailto:abbieb@nortelnetworks.com]<BR><B>Sent:</B> Wednesday, =
October 23,=20
    2002 10:19 AM<BR><B>To:</B> eburger@snowshore.com; OPES=20
    Group<BR><B>Subject:</B> RE: Unique Shared Secrets (4.4.2) in=20
    opes-authorization<BR><BR></FONT></DIV><BR>
    <P><FONT size=3D2>eric,</FONT> </P>
    <P><FONT size=3D2>The intend here is to secure the Hop-by-hop =
traffic. We can=20
    reaxime the wording and the requirements.</FONT> </P>
    <P><FONT size=3D2>-- This will be added as an action item for the =
-01=20
    draft.</FONT> </P>
    <P><FONT size=3D2>Abbie</FONT> </P><BR><BR>
    <P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;=20
    From: Eric Burger [<A=20
    =
href=3D"mailto:eburger@snowshore.com">mailto:eburger@snowshore.com</A>]=20
    </FONT><BR><FONT size=3D2>&gt; Sent: Monday, October 21, 2002 10:35 =
PM</FONT>=20
    <BR><FONT size=3D2>&gt; To: OPES Group</FONT> <BR><FONT =
size=3D2>&gt; Subject:=20
    Unique Shared Secrets (4.4.2) in opes-authorization</FONT> <BR><FONT =

    size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
    </FONT><BR><FONT size=3D2>&gt; Why must the shared secrets be unique =
for each=20
    requestor / </FONT><BR><FONT size=3D2>&gt; responder pair? Why do we =

    care?&nbsp; In fact, such a requirement </FONT><BR><FONT =
size=3D2>&gt; opens a=20
    security hole: I can guess someone else's key by </FONT><BR><FONT=20
    size=3D2>&gt; trying to enter keys until the "system" tells me I =
can't=20
    </FONT><BR><FONT size=3D2>&gt; because someone else has that =
key.</FONT>=20
    <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; I would drop =
the=20
    bullet.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  </FONT></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C27ECE.FEF56524--


From owner-ietf-openproxy@mail.imc.org  Tue Oct 29 06:42:45 2002
Received: from above.proper.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29357
	for <opes-archive@ietf.org>; Tue, 29 Oct 2002 06:42:44 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g9TBIBG14948
	for ietf-openproxy-bks; Tue, 29 Oct 2002 03:18:11 -0800 (PST)
Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TBIAW14939
	for <ietf-openproxy@imc.org>; Tue, 29 Oct 2002 03:18:10 -0800 (PST)
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9TBHuO01355;
	Tue, 29 Oct 2002 06:17:56 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <TLKCKZCD>; Tue, 29 Oct 2002 06:17:56 -0500
Message-ID: <87609AFB433BD5118D5E0002A52CD75403FC330B@zcard0k6.ca.nortel.com>
From: "Abbie Barbir" <abbieb@nortelnetworks.com>
To: bindignavile.srinivas@nokia.com, eburger@snowshore.com,
        ietf-openproxy@imc.org
Subject: RE: Unique Shared Secrets (4.4.2) in opes-authorization
Date: Tue, 29 Oct 2002 06:17:51 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C27F3C.D1E84742"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C27F3C.D1E84742
Content-Type: text/plain

Sirini,
 
thanks for  the feedback. we will add this as an action item for the -01
draft.
 
abbie
 

-----Original Message-----
From: bindignavile.srinivas@nokia.com
[mailto:bindignavile.srinivas@nokia.com] 
Sent: Monday, October 28, 2002 4:07 PM
To: Barbir, Abbie [CAR:1A00:EXCH]; eburger@snowshore.com;
ietf-openproxy@imc.org
Subject: RE: Unique Shared Secrets (4.4.2) in opes-authorization


Hi,
I had a look at the opes-authorization draft again, and I too was not really
convinced of the need for "unique" shared secrets for each
requestor/responder pair. The only way I can see for the integrity and
confidentiality of OPES data (application) flow to be compromised is:
 
1. Two different data streams (with different "content consumers" and same
or different "content providers") share the same OPES device.
2. One of the two CC's is malicious.
3. In this event, if the shared secrets for each requestor/responder pair
are not unique, then the integrity and confidentiality of OPES data could be
compromised.
 
However, if all the OPES CC's can be trusted, then uniqueness is not needed,
IMHO!
 
-Srini

-----Original Message-----
From: ext Abbie Barbir [mailto:abbieb@nortelnetworks.com]
Sent: Wednesday, October 23, 2002 10:19 AM
To: eburger@snowshore.com; OPES Group
Subject: RE: Unique Shared Secrets (4.4.2) in opes-authorization




eric, 

The intend here is to secure the Hop-by-hop traffic. We can reaxime the
wording and the requirements. 

-- This will be added as an action item for the -01 draft. 

Abbie 



> -----Original Message----- 
> From: Eric Burger [mailto:eburger@snowshore.com
<mailto:eburger@snowshore.com> ] 
> Sent: Monday, October 21, 2002 10:35 PM 
> To: OPES Group 
> Subject: Unique Shared Secrets (4.4.2) in opes-authorization 
> 
> 
> 
> Why must the shared secrets be unique for each requestor / 
> responder pair? Why do we care?  In fact, such a requirement 
> opens a security hole: I can guess someone else's key by 
> trying to enter keys until the "system" tells me I can't 
> because someone else has that key. 
> 
> I would drop the bullet. 
> 
> 


------_=_NextPart_001_01C27F3C.D1E84742
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2713.1100" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=403151611-29102002>Sirini,</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=403151611-29102002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=403151611-29102002>thanks 
for&nbsp; the feedback. we will add this as an action item for the -01 
draft.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=403151611-29102002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=403151611-29102002>abbie</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=403151611-29102002></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT 
  face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> 
  bindignavile.srinivas@nokia.com [mailto:bindignavile.srinivas@nokia.com] 
  <BR><B>Sent:</B> Monday, October 28, 2002 4:07 PM<BR><B>To:</B> Barbir, Abbie 
  [CAR:1A00:EXCH]; eburger@snowshore.com; 
  ietf-openproxy@imc.org<BR><B>Subject:</B> RE: Unique Shared Secrets (4.4.2) in 
  opes-authorization<BR><BR></FONT></DIV>
  <DIV><SPAN class=755405220-28102002><FONT face=Arial color=#0000ff 
  size=2>Hi,</FONT></SPAN></DIV>
  <DIV><SPAN class=755405220-28102002><FONT face=Arial color=#0000ff size=2>I 
  had a look at the opes-authorization draft again, and I too was not really 
  convinced of the need for "unique" shared secrets&nbsp;for each 
  requestor/responder pair. The only way I can see for the integrity and 
  confidentiality of OPES data (application) flow to be compromised 
  is:</FONT></SPAN></DIV>
  <DIV><SPAN class=755405220-28102002><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=755405220-28102002><FONT face=Arial color=#0000ff size=2>1. 
  Two different data streams (with different "content consumers" and same or 
  different "content providers") share the same OPES device.</FONT></SPAN></DIV>
  <DIV><SPAN class=755405220-28102002><FONT face=Arial color=#0000ff size=2>2. 
  One of the two CC's is malicious.</FONT></SPAN></DIV>
  <DIV><SPAN class=755405220-28102002><FONT face=Arial color=#0000ff size=2>3. 
  In this event, if the shared secrets for each requestor/responder 
  pair&nbsp;are not unique, then the integrity and confidentiality of OPES data 
  could be compromised.</FONT></SPAN></DIV>
  <DIV><SPAN class=755405220-28102002><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=755405220-28102002><FONT face=Arial color=#0000ff 
  size=2>However, if all the OPES CC's can be trusted, then uniqueness is not 
  needed, IMHO!</FONT></SPAN></DIV>
  <DIV><SPAN class=755405220-28102002><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=755405220-28102002><FONT face=Arial color=#0000ff 
  size=2>-Srini</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=ltr 
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> ext Abbie Barbir 
    [mailto:abbieb@nortelnetworks.com]<BR><B>Sent:</B> Wednesday, October 23, 
    2002 10:19 AM<BR><B>To:</B> eburger@snowshore.com; OPES 
    Group<BR><B>Subject:</B> RE: Unique Shared Secrets (4.4.2) in 
    opes-authorization<BR><BR></FONT></DIV><BR>
    <P><FONT size=2>eric,</FONT> </P>
    <P><FONT size=2>The intend here is to secure the Hop-by-hop traffic. We can 
    reaxime the wording and the requirements.</FONT> </P>
    <P><FONT size=2>-- This will be added as an action item for the -01 
    draft.</FONT> </P>
    <P><FONT size=2>Abbie</FONT> </P><BR><BR>
    <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
    From: Eric Burger [<A 
    href="mailto:eburger@snowshore.com">mailto:eburger@snowshore.com</A>] 
    </FONT><BR><FONT size=2>&gt; Sent: Monday, October 21, 2002 10:35 PM</FONT> 
    <BR><FONT size=2>&gt; To: OPES Group</FONT> <BR><FONT size=2>&gt; Subject: 
    Unique Shared Secrets (4.4.2) in opes-authorization</FONT> <BR><FONT 
    size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; Why must the shared secrets be unique for each 
    requestor / </FONT><BR><FONT size=2>&gt; responder pair? Why do we 
    care?&nbsp; In fact, such a requirement </FONT><BR><FONT size=2>&gt; opens a 
    security hole: I can guess someone else's key by </FONT><BR><FONT 
    size=2>&gt; trying to enter keys until the "system" tells me I can't 
    </FONT><BR><FONT size=2>&gt; because someone else has that key.</FONT> 
    <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; I would drop the 
    bullet.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  </FONT></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C27F3C.D1E84742--