Re: [proxies] [IETF Proxy] Next Steps

Stefan Winter <stefan.winter@restena.lu> Thu, 17 April 2008 13:51 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 9A06528C0D0; Thu, 17 Apr 2008 06:51:14 -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 55A123A6D2D for <proxies@core3.amsl.com>; Thu, 17 Apr 2008 06:51:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.055
X-Spam-Level:
X-Spam-Status: No, score=0.055 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_40=-0.185, 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 PdT69GtYhR+e for <proxies@core3.amsl.com>; Thu, 17 Apr 2008 06:51:00 -0700 (PDT)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) by core3.amsl.com (Postfix) with ESMTP id DC0F128C53C for <proxies@ietf.org>; Thu, 17 Apr 2008 06:50:11 -0700 (PDT)
Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 8203676F44 for <proxies@ietf.org>; Thu, 17 Apr 2008 15:50:49 +0200 (CEST)
Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTP id 7263376F42 for <proxies@ietf.org>; Thu, 17 Apr 2008 15:50:49 +0200 (CEST)
From: Stefan Winter <stefan.winter@restena.lu>
Organization: Fondation RESTENA
To: proxies@ietf.org
Date: Thu, 17 Apr 2008 15:50:43 +0200
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <7.0.1.0.2.20080416172531.02401228@nist.gov>
In-Reply-To: <7.0.1.0.2.20080416172531.02401228@nist.gov>
X-Face: %j?V+uSSM.S0%383/M#=_w?DsL5os9fxa%z-TN:))c[W7~6eK)=2ek5>=?utf-8?q?=5Ed+=3B=5Dk=2EwY4k1ve=0A=092=23=5EC=5EstMo*JDE=3FS2YkN=3At=7E?= =?utf-8?q?Vv=7D?=(exS~'/q+xqA<acFY(btkiR{eKogv`i=}e.q-> =?utf-8?q?KPf6=7E=5B=3B=0A=09=27=2EB=27=2EDkOdU6gj-r=23ei=7D=23d=60=3B?= =?utf-8?q?B=7C*8awL3HM-=5C=3DR?=>Z<(33?+#W+:Fy)TH&)Q({@ =?utf-8?q?ZBHm=26d8LZ=24=0A=09M/L!033=7CZlf7?=(=d<{]y!'$TmaI\276$)iMlA@A*ZA&q>W5"rsQ)FHGBp)<B6I`c8-M\N"" =?utf-8?q?=0A=09=3FQj!+=60YSi=3AXV7a7mZbH!Q=3FsCW?=)Mj_Vkm@*^Wzmv1qB%$+_@$[?I
MIME-Version: 1.0
Message-Id: <200804171550.48931.stefan.winter@restena.lu>
X-Virus-Scanned: ClamAV using ClamSMTP
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: multipart/mixed; boundary="===============1425558691=="
Sender: proxies-bounces@ietf.org
Errors-To: proxies-bounces@ietf.org

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