Re: [proxies] [IETF Proxy] Next Steps

"Dan Harkins" <dharkins@lounge.org> Mon, 05 May 2008 18:48 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 8BC6E3A6C19; Mon, 5 May 2008 11:48:48 -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 E41E03A6BF5 for <proxies@core3.amsl.com>; Mon, 5 May 2008 11:48:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.935
X-Spam-Level:
X-Spam-Status: No, score=0.935 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=0.6]
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 lTeJEKp87ETj for <proxies@core3.amsl.com>; Mon, 5 May 2008 11:48:46 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id C354F3A6866 for <proxies@ietf.org>; Mon, 5 May 2008 11:48:46 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id BA0CD10224078; Mon, 5 May 2008 11:48:45 -0700 (PDT)
Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 5 May 2008 11:48:45 -0700 (PDT)
Message-ID: <057433e024b8d47267adf9fd0379bd6b.squirrel@www.trepanning.net>
In-Reply-To: <200804171550.48931.stefan.winter@restena.lu>
References: <7.0.1.0.2.20080416172531.02401228@nist.gov> <200804171550.48931.stefan.winter@restena.lu>
Date: Mon, 5 May 2008 11:48:45 -0700 (PDT)
From: "Dan Harkins" <dharkins@lounge.org>
To: "Stefan Winter" <stefan.winter@restena.lu>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
X-Priority: 3 (Normal)
Importance: Normal
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: proxies-bounces@ietf.org
Errors-To: proxies-bounces@ietf.org

  It has been pointed out to me that I may be misunderstanding Stefan's
intent by latching on the word "political" and running with it.

  I do not mean to attack any valid uses of proxies that may fall under
the "political" rubric but I do believe there are threats that should
be enumerated for proxies that can do things like compile databases of
information gleaned from AAA traffic that goes through them, or locate
and track people. And the mention of "political" requirements brought
that up (in my mind at least).

  Dan.

On Thu, April 17, 2008 6:50 am, Stefan Winter wrote:
> Hello,
>
>> Instead of continuing our heated debate from Philadelphia, I propose
>> to choose a more directed & organized path [fill in jokes about
>> Germans]
>
> We need forms. Stamps. At least five layers of administrative hierarchy,
> where
> the required procedures of all layers are incompatible to each other.
>
> [Take it easy, I am German myself ;-) ]
>
>>   1. Define Use Cases
>> -       describe typical current and future scenarios/applications in
>> which  proxies are used
>> -       describe the role and capabilities (e.g. knowledge of
>> information and/or keying material) of proxies and other network
>> entities in these use cases
>> -       describe network architectures of use cases
>
> As I noted during the introductory round, Klaas and me are heavily
> involved in
> a worldwide Wireless LAN roaming consortium called "eduroam" for the
> educational and research community. Our operational model includes lots of
> proxies. So I'll give a sketch about our architecture here, hoping it
> helps
> to identify use cases.
>
> eduroam is comprised of independent administrative domains: universities,
> research centres etc. There are currently several hundred of those
> domains,
> aspiring to a thousand. These domains are geographically mostly in Europe,
> with a small outreach into the Asia-Pacific area.
> The scale of this consortium made it seem impractical to aggregate all
> world-wide participants into a single clearinghouse. (More detailed, the
> reason was threefold: evading a single point of failure which would render
> all roaming ops impossible if unavailable; amount of re-configurations and
> corresponding outages on a single server was deemed inacceptable for the
> sheer number of participants; and also the political unwillingness for
> participating nations to rely on a clearinghouse instance in some distant
> country).
> Instead, the model was to aggregate the participating domains in a
> two-stage
> approach: aggregate domains within a country to a national server,
> aggregate
> national servers to an international root server. As time passed and
> Asia-Pacific became more active, two roots emerged, a European and an APAN
> one, peering with each other.
>
> From our operational experience so far, we have seen both problems and
> blessings of proxies (I use proxy here as: neither being the service
> provider's server in the visited domain nor the home server of the user).
>
> The "blessing" part:
>
> There were countries that wanted to execute tight control over their
> participants and filter authentication traffic. Using a national proxy
> naturally fitted their subjective need for control. When speaking about
> dynamic server discovery in RadSec, which might make national aggregation
> prxies obsolete, the answer from this kind of people was: nice thing, but
> we'll make sure all dynamic discovery for our domains will point to our
> national server.
>
> The "problem" part:
>
> It turned out that in addition to the pure authentication information that
> is
> user-supplied, it is in some cases necessary for home and service provider
> server to speak to each other *about* the user. The most prominent example
> here is: in Australia, unfiltered Internet access is only allowed for
> adults.
> So if a foreign eduroam user authenticates within Australia, the visited
> domain needs to get information about the age of the user. 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. These are heavily regulated in the EU, introducing
> a
> legal problem (I'll save you from the details).
>
> To me, the above model seems to have two role models of proxies:
>
> - the "technical" proxy - to aggregate or channelize traffic for
> managability
> reasons
> - the "political" proxy - due to the requirement or wish to inspect,
> control
> or modify traffic while in flight
>
> The first kind might go away with dynamic discovery between service
> provider
> and home server; the second might most certainly not. So my answer to the
> proxy problem in general is: we will have to live with them.
>
>> 2. Define Threat Model
>> -       define trust model for all network entities including proxies
>> and their relationships to each other
>> -       analyze how proxies can launch attacks in the defined use
>> cases, i.e. what are the threats?
>
> 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
>
>> 3. Analyze the feasibility and severity of the identified threats
>
> - It is technically trivial to sniff RADIUS traffic (except for very few
> attributes). Diameter or RadSec or RADIUS+DTLS don't help if proxies are
> in
> between: all these define only AAA-hop to AAA-hop security, so all
> intermediate proxies will have access to the transmitted information. A
> possible mitigation of the risk could include legal threats for the
> proxying
> entity for the case of abusing the relayed data.
>
> - 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.
>
> Greetings,
>
> Stefan Winter
>
> --
> Stefan WINTER
>
> Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et
> de
> la Recherche
> Ingenieur Forschung & Entwicklung
>
> 6, rue Richard Coudenhove-Kalergi
> L-1359 Luxembourg
> E-Mail: stefan.winter@restena.lu     Tel.:     +352 424409-1
> http://www.restena.lu                Fax:      +352 422473
> _______________________________________________
> Proxies mailing list
> Proxies@ietf.org
> https://www.ietf.org/mailman/listinfo/proxies
>


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