Re: [proxies] [IETF Proxy] Next Steps

[Stefan Winter <[e-mail]>]

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: [e-mail]     Tel.:     [phone]
http://www.restena.lu                Fax:      [phone]

_______________________________________________
Proxies mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/proxies