Re: [proxies] Recap for -00 draft
Alan DeKok <aland@nitros9.org> Fri, 02 May 2008 16:07 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 5DC3E28C1BC; Fri, 2 May 2008 09:07:15 -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 B7A423A67D0 for <proxies@core3.amsl.com>; Fri, 2 May 2008 09:07:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 uFt3QD7uypdK for <proxies@core3.amsl.com>; Fri, 2 May 2008 09:07:00 -0700 (PDT)
Received: from deployingradius.com (www.deployingradius.com [216.240.42.17]) by core3.amsl.com (Postfix) with ESMTP id 670023A6A5E for <proxies@ietf.org>; Fri, 2 May 2008 09:06:37 -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 9F25CA7052 for <proxies@ietf.org>; Fri, 2 May 2008 09:06:35 -0700 (PDT)
Message-ID: <481B3B12.6010507@nitros9.org>
Date: Fri, 02 May 2008 18:02:26 +0200
From: Alan DeKok <aland@nitros9.org>
User-Agent: Thunderbird 2.0.0.12 (X11/20080227)
MIME-Version: 1.0
To: proxies@ietf.org
References: <7.0.1.0.2.20080502100208.023e9f60@nist.gov>
In-Reply-To: <7.0.1.0.2.20080502100208.023e9f60@nist.gov>
Subject: Re: [proxies] Recap for -00 draft
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="utf-8"
Content-Transfer-Encoding: base64
Sender: proxies-bounces@ietf.org
Errors-To: proxies-bounces@ietf.org
Katrin Hoeper wrote: > I. USE CASE > 1) a worldwide WLAN that enables roaming registered users to access > information free of charge > (thanks Stefan for your detailed description) I'll see if I can write up a description of a commercial global roaming system. > II. THREATS: > 1) proxies can listen to traffic > 2) insert fake accounting packets - users can use stolen credentials - visited networks can listen to traffic - visited networks can insert fake accounting packets - home network can authenticate the user, and then refuse to pay the proxy or the visited network > III. FEASIBILIY > -easy to sniff traffic for proxies > -most attributes readable due to AAA hop-by-hop security - everyone in the "AAA trust" boundary can see all of the traffic, and lie about any of it. > IV. SEVERITY > -depends on the content of the exchanged data > When data contains valuable user information (such as the user’s age), > this information can be correlated with the user identity and then be > exploited. > -depends on national laws and regulations > -depends on whether offered services are free or paid > > -some providers seem to be more worried about malicious insiders and > outsider sniffers rather than proxies I would add a section "mitigating factors". These are not *solution*, but pragmatic self-interest. - if the visited networks have a pattern of theft/fraud, the proxies and/or home networks will refuse to work with them - if the proxies have a pattern of theft/fraud, the visited and/or home networks will refuse to work with them - if the home networks have a pattern of refusal to pay bills, the visited networks / proxies will refuse to work with them - if a user has a pattern of theft/fraud, the home network will refuse to authorize their access i.e. as soon as someone gets caught doing bad things, it's in everyone else's interest to kick them out of the AAA network. Also: - home networks inform proxies / visited networks about limits on their willingness to pay. e.g. "allow 10 minutes of access" - visited networks are responsible for enforcing these limits - home networks refuse to pay for access outside of those limits after all... the visited network was *told* to hang up. If it doesn't, the home network isn't responsible for the bill - the visited network is responsible for informing the proxies and home network that the user is still online, and what they are doing (time/traffic accounting). If they stop, the home network can assume that the user has logged off, and refuse to pay for further service. - if mid-session disconnection is supported, the home network can inform the visited network to disconnect the user. Again, the visited network does this, because the home network will refuse to pay for service after a disconnection request has been sent. > Please send other information that you would like to be included in the > 00 draft to the list. Also let me know if you disagree with previous > discussions (items I-IV, not solutions!). Off course, everybody is more > than welcome to volunteer as a co-author. Just let me know. I'm interested, but I don't know how much time I have. > We definitely need more use cases. I will try to cover all aspects > listed under IV. Severity in the use cases. It would be very helpful if > people could send me more “real implementation” examples of networks > using proxies, especially the architecture of such networks and the > particular functions of proxies in them (e.g. what data do they need to > know). I'll grab some diagrams and send them over. As for the data the proxies need to know... it's as much data as the visited network can supply. Which is usually nothing more than user identification, visited network identification (access points, etc.), data traffic in/out, and session time. Everyone would like to get more data, but the equipment at the visited networks is so old that it often doesn't support 8 year-old standards. Alan DeKok. _______________________________________________ Proxies mailing list Proxies@ietf.org https://www.ietf.org/mailman/listinfo/proxies
- [proxies] Recap for -00 draft Katrin Hoeper
- Re: [proxies] Recap for -00 draft Alan DeKok
- Re: [proxies] Recap for -00 draft Bernard Aboba