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
- [proxies] [IETF Proxy] Next Steps Katrin Hoeper
- Re: [proxies] [IETF Proxy] Next Steps Stefan Winter
- Re: [proxies] [IETF Proxy] Next Steps Alan DeKok
- Re: [proxies] [IETF Proxy] Next Steps Stefan Winter
- Re: [proxies] [IETF Proxy] Next Steps Glen Zorn
- Re: [proxies] [IETF Proxy] Next Steps Stefan Winter
- Re: [proxies] [IETF Proxy] Next Steps Glen Zorn
- Re: [proxies] [IETF Proxy] Next Steps Katrin Hoeper
- Re: [proxies] [IETF Proxy] Next Steps Stefan Winter
- Re: [proxies] [IETF Proxy] Next Steps Bernard Aboba
- Re: [proxies] [IETF Proxy] Next Steps Dan Harkins
- Re: [proxies] [IETF Proxy] Next Steps Alan DeKok
- Re: [proxies] [IETF Proxy] Next Steps Bernard_Aboba
- Re: [proxies] [IETF Proxy] Next Steps Bernard_Aboba
- Re: [proxies] [IETF Proxy] Next Steps Glen Zorn
- Re: [proxies] [IETF Proxy] Next Steps Dan Harkins
- Re: [proxies] [IETF Proxy] Next Steps Dan Harkins
- Re: [proxies] [IETF Proxy] Next Steps Stefan Winter
- Re: [proxies] [IETF Proxy] Next Steps Klaas Wierenga
- Re: [proxies] [IETF Proxy] Next Steps Glen Zorn
- Re: [proxies] [IETF Proxy] Next Steps Klaas Wierenga
- Re: [proxies] [IETF Proxy] Next Steps Stefan Winter
- Re: [proxies] [IETF Proxy] Next Steps Klaas Wierenga