Re: [proxies] [IETF Proxy] Next Steps

Katrin Hoeper <> Fri, 02 May 2008 14:02 UTC

Return-Path: <>
Received: from (localhost []) by (Postfix) with ESMTP id CC18128C118; Fri, 2 May 2008 07:02:01 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 20B4A3A6A63 for <>; Fri, 2 May 2008 07:02:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.613
X-Spam-Status: No, score=-3.613 tagged_above=-999 required=5 tests=[AWL=-1.611, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LecC9oefVFTv for <>; Fri, 2 May 2008 07:01:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3192E3A68FC for <>; Fri, 2 May 2008 07:01:58 -0700 (PDT)
Received: from ( []) by (8.13.1/8.13.1) with ESMTP id m42E1ttP032473; Fri, 2 May 2008 10:01:56 -0400
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Fri, 02 May 2008 10:01:55 -0400
To: Stefan Winter <>,
From: Katrin Hoeper <>
In-Reply-To: <>
References: <> <>
Mime-Version: 1.0
X-NIST-MailScanner: Found to be clean
Subject: Re: [proxies] [IETF Proxy] Next Steps
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion list for ad hoc group interested in security and proxies <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============0367025773=="

Hi Stefan,

thank you for your very detailed example. It's a great basis for discussion.

Could you please provide some kind of diagram 
with the network architecture, including root 
servers, national proxies and servers?
I just would like to clarify some things before I 
can adopt your example as a use case for the 00 draft.


At 09:50 AM 4/17/2008, Stefan Winter wrote:
> > 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
>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
>- 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.
>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:     Tel.:     +352 424409-1
>                Fax:      +352 422473
>Proxies mailing list

Katrin Hoeper
Computer Security Division
National Institute of Standards and Technology (NIST)
100 Bureau Dr. Mail stop: 8930
Gaithersburg, MD 20899
(301) 975 - 4024
Proxies mailing list