Re: [proxies] [IETF Proxy] Next Steps

[Katrin Hoeper <[e-mail]>]

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.

Thanks,
Katrin

At 09:50 AM 4/17/2008, 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: [e-mail] Â  Â  Tel.:  Â  Â [phone]
>http://www.restena.lu                Fax:      [phone]
>
>
>_______________________________________________
>Proxies mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/proxies


----------
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
[e-mail]
https://www.ietf.org/mailman/listinfo/proxies