Re: [proxies] [IETF Proxy] Next Steps

Alan DeKok <aland@nitros9.org> Thu, 17 April 2008 15:19 UTC

Return-Path: <proxies-bounces@ietf.org>
X-Original-To: proxies-archive@ietf.org
Delivered-To: ietfarch-proxies-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5B8F28C24D; Thu, 17 Apr 2008 08:19:09 -0700 (PDT)
X-Original-To: proxies@core3.amsl.com
Delivered-To: proxies@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 896763A6BF6 for <proxies@core3.amsl.com>; Thu, 17 Apr 2008 08:19:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.547
X-Spam-Level:
X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfZCzm3cdlYm for <proxies@core3.amsl.com>; Thu, 17 Apr 2008 08:19:06 -0700 (PDT)
Received: from deployingradius.com (www.deployingradius.com [216.240.42.17]) by core3.amsl.com (Postfix) with ESMTP id 23F6A3A6F68 for <proxies@ietf.org>; Thu, 17 Apr 2008 08:19:05 -0700 (PDT)
Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by deployingradius.com (Postfix) with ESMTP id AA2C2A7136; Thu, 17 Apr 2008 08:19:40 -0700 (PDT)
Message-ID: <480769A1.9080408@nitros9.org>
Date: Thu, 17 Apr 2008 17:15:45 +0200
From: Alan DeKok <aland@nitros9.org>
User-Agent: Thunderbird 2.0.0.12 (X11/20080227)
MIME-Version: 1.0
To: Stefan Winter <stefan.winter@restena.lu>
References: <7.0.1.0.2.20080416172531.02401228@nist.gov> <200804171550.48931.stefan.winter@restena.lu>
In-Reply-To: <200804171550.48931.stefan.winter@restena.lu>
Cc: proxies@ietf.org
Subject: Re: [proxies] [IETF Proxy] Next Steps
X-BeenThere: proxies@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion list for ad hoc group interested in security and proxies <proxies.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/proxies>, <mailto:proxies-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:proxies@ietf.org>
List-Help: <mailto:proxies-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/proxies>, <mailto:proxies-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: proxies-bounces@ietf.org
Errors-To: proxies-bounces@ietf.org

Stefan Winter wrote:
> So if a foreign eduroam user authenticates within Australia, the visited 
> domain needs to get information about the age of the user.

  IANAL, but there are adults who are not legally responsible for their
actions.  Requiring that the users be "legally responsible" may satisfy
the constraint, while exposing minimal information.

> Without proxies, 
> this would not be a problem: define a Vendor-Specific attribute and 
> communicate the value. With proxies, things are worse: the traffic will be 
> sent through intermediate proxy servers, which can then correlate the 
> information of the age to the user identity, and thus create personally 
> identifiable data sets.

  It gets worse than that.  How does one end express a query that the
other end can understand?  This involves defining a fairly complex
policy language.  So far, all attempts to define a usable policy
language have failed.

> Being an architect of our hierarchy myself, I might have blind spots. Anyway, 
> there is at least one identifiable threat in the above model:
> 
> - proxies can intercept data they are not entitled for and abuse it

  Yes.  Non-technical means exist to address this problem.

> - Severity: that depends heavily on one's personal view on privacy and 
> confidentiality of personal data and its weight in today's world. I don't 
> want to make a blanket statement here.

  The people I talk to indicate that they are more worried about users
abusing the system than insiders.

  e.g. wireless sniffers at a hotspot are a problem.  Malicious proxies
aren't.

  I do think we need a documentation explaining the possible
architectures, the threats, requirements, and judged risks.

  Alan DeKok.
_______________________________________________
Proxies mailing list
Proxies@ietf.org
https://www.ietf.org/mailman/listinfo/proxies