Subject: Re: [proxies] [IETF Proxy] Next Steps

From: Katrin Hoeper <[email-masked]>
Date: Fri, 02 May 2008 10:01:55 -0400

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: [email-masked] Â  Â  Tel.:  Â  Â +352 424409-1
>http://www.restena.lu Â  Â  Â  Â  Â  Â   Â  Fax: Â  Â  Â +352 422473
>
>
>_______________________________________________
>Proxies mailing list
>[email-masked]
>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
[email-masked]
https://www.ietf.org/mailman/listinfo/proxies

---

From: Stefan Winter <[email-masked]>
Date: Fri, 02 May 2008 16:12:52 +0200

Hi Katrin,

there's certainly no shortage of powerpoint slides about our
architecture :-) Attached a PostScript version.

The number of "institutional servers" ranges from 1 to ~50 per
"federation" (our fancy word for national aggregation servers) and there
are currently 33 federations within the European "confederation" (which
is a again a fancy word for: root aggregation servers).

Greetings,

Stefan

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 2 May 2008 15:23:57 -0700

Stefan said:
 
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).
 
[BA] Wouldn't EU regulations have a problem with the local ISP obtaining the age of the user, irrespective of proxies?  Also, why can't the problem (with or without proxies) be solved using the CUI, described in RFC 4372?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 flightThe 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.
 
[BA] I think these issues are described in RFC 2607, no?

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 2 May 2008 16:06:51 -0700 (PDT)

Hi Stefan,

On Thu, April 17, 2008 6:50 am, Stefan Winter wrote:
[snip]
> proxy problem in general is: we will have to live with them.

  This political proxy thing concerns me. The only traffic that a AAA proxy
could inspect, control or modify is AAA traffic. So what this entity would
do is glean information about who is using what network where and, in
some cases, prevent some people somewhere from using some network.

  These are not things that I think we _have_ to deal with especially in
a technical forum. These are issues that a customer will require a vendor
of AAA product to support, in much the same way that "lawful intercept"
is a political add-on to a technical solution-- e.g. the IPsec WG did not
architect "lawful intercept" into RFC2401 but people that have implemented
IPsec have added backdoors into their products to allow for it. I'm sure
that some RFP somewhere will mandate, if it doesn't already, that
evesdropping and controlling entities be required in between AAA client
and AAA server but that isn't really the problemspace we're dealing with.

  I have heard many other reasons why AAA proxies must exist. If a magic
wand made all those reasons disappear I really hope this political
justification would not keep them around. (Note: I'm not entertaining the
notion of getting rid of proxies, just theorizing, so don't attack me).

  This does highlight threats though. It's not just that proxies can
listen to AAA exchanges, they can glean information out of AAA exchanges,
and they can constrain or deny service that should otherwise be
unconstrained or allowed.

  Dan.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 03 May 2008 07:43:19 +0200

Dan Harkins wrote:
> could inspect, control or modify is AAA traffic.

  I think that's what Stefan meant.

  In the commercial world, proxies do this, too.  A visited network may
not supply information in a form needed by the home network, and vice
versa.  The intermediary proxies are responsible for "fixing" the AAA
information inbound and outbound, so that everyone else doesn't have to
change their systems.

> So what this entity would

  In Stefan's case, yes.  Some countries have their educational networks
run or coordinated from a central body.  In those countries, the body
*is* responsible, and *can* control the network.  They simply want to
use existing powers on new systems, such as AAA proxies.

  In the commercial world, proxies are contractually forbidden from
interfering with the status of the user.  They can change the contents
of the packets, but not the accept/deny status of the user.

> is a political add-on to a technical solution--

  I'd like to see a document making this distinction clear for everyone.

> notion of getting rid of proxies, just theorizing, so don't attack me).

  Proxies won't be disappearing.  Business politics and efficiencies
mean that it's often easier && cheaper to outsource to a dedicated AAA
proxy.

> unconstrained or allowed.

  Absolutely.

  Alan DeKok.

---

From: <[email-masked]>
Date: Fri, 2 May 2008 23:08:01 -0700

> a technical forum.

I would agree.   In years of previous discussion, including published
RFCs dealing with the proxy threat model, the assumption has always
been that the IETF's goal is to enable the deployment of secure systems.
The goal of enabling surveillance, information gathering, or unlawful
intercept has not previously been a goal.

The point of this is I think, that one cannot have a rational discussion
of security measures, if in fact, the goal is actually to enable backdoors.
A system that is engineered to provide a backdoor will inevitably
(surprise!) be found to have a security vulnerability.

So I think we need to be very explicit about what we are trying to
achieve -- and also, we need to be very clear about the actual
extent of the problem today.

>  I have heard many other reasons why AAA proxies must exist.

The functions of proxies are described in some detail in RFC 2607, Section 
4.1.

> unconstrained or allowed.

It is also possible that proxies can allow service that might otherwise be
denied (even though this is forbidden by RFC 2607 Section 5.1).   However,
as described in RFC 2607 Section 5.2, the implementation of "policy"
typically applies to authentication/authorization, but not to accounting.

---

From: <[email-masked]>
Date: Fri, 2 May 2008 23:11:39 -0700

>  I'd like to see a document making this distinction clear for everyone.

Yes.  Personally, I find it unnerving when vendors cite requests from 
government
agencies as the basis for engineering decisions that cannot be justified on 
technical
grounds.  Implementers are perfectly capable of shipping software with 
security
vulnerabilities that enable miscreants to take control without being 
assisted in that
task by design flaws inserted by the IETF.

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 3 May 2008 13:55:47 -0700

[email-masked] <> scribbled on Friday, May 02, 2008 4:07 PM:

>> - 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.
> 
>  This political proxy thing concerns me. The only traffic
> that a AAA proxy could inspect, control or modify is AAA
> traffic. So what this entity would do is glean information
> about who is using what network where and, in some cases,
> prevent some people somewhere from using some network.
> 
>  These are not things that I think we _have_ to deal with
> especially in a technical forum. These are issues that a
> customer will require a vendor of AAA product to support, in
> much the same way that "lawful intercept"
> is a political add-on to a technical solution-- e.g. the IPsec
> WG did not architect "lawful intercept" into RFC2401 but
> people that have implemented IPsec have added backdoors into
> their products to allow for it. 

If the "security gateway" is not an architected listening post, what is
it?

> I'm sure that some RFP
> somewhere will mandate, if it doesn't already, that
> evesdropping and controlling entities be required in between
> AAA client and AAA server but that isn't really the
> problemspace we're dealing with.

Things aren't quite as sinister as you seem to imagine, Dan.  Attributes
may be added or removed for perfectly valid operational reasons; that is
exactly the problemspace with which we're dealing.  It's not always
either possible or appropriate for the home AAA server to be aware of
the correct parameters to be supplied to a visited NAS, for example...

> If a magic wand made all those reasons disappear I really hope
> this political justification would not keep them around.
> (Note: I'm not entertaining the notion of getting rid of
> proxies, just theorizing, so don't attack me).
> 
>  This does highlight threats though. It's not just that
> proxies can listen to AAA exchanges, they can glean
> information out of AAA exchanges, and they can constrain or
> deny service that should otherwise be unconstrained or allowed.

Hmm.  Substitute "would" for "should" & it seems to me that you have
just restated a definition of the term "authorization".
_______________________________________________
Proxies mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/proxies

---

From: "Dan Harkins" <[email-masked]>
Date: Sat, 3 May 2008 17:21:15 -0700 (PDT)

Hi Glen,

> If the "security gateway" is not an architected listening post, what is

  It's an architected security gateway that secures traffic based on a
well-defined policy. By the nature of the beast at least one of its
interfaces will probably be unsecured and traffic on the network on
which that interface is connected can be snarfed. But that doesn't mean
it's an "architected listening post".

  If the vendor added what we used to call "service spy mode" where it
would T-off specified traffic and send one copy to the intended destination
and another to some nefarious location then that would be in line with
what I was talking about.

  But "service spy mode" is not part of the IPsec specification. It's
a political add-on that certain vendors have added after they were asked
for it.

> the correct parameters to be supplied to a visited NAS, for example...

  Once again, you're missing the point. Perfectly valid operational issues
are one thing. Mandating something for purely political reasons-- to
enable evesdropping or tracking-- is quite another. And I don't think
these political motivations justify proxys in any way.

> just restated a definition of the term "authorization".

  So? It's a threat. A tool used inappropriately can be a weapon. Cars,
guns, even plastic bags come with threat warnings describing what can
happen if not used properly. I think it deserves mentioning what problems
can arise if proxies are used inappropriately.

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 5 May 2008 11:48:45 -0700 (PDT)

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:
> We need forms. Stamps. At least five layers of administrative hierarchy,
> where
> As I noted during the introductory round, Klaas and me are heavily
> involved in
> managability
> provider

---

From: Stefan Winter <[email-masked]>
Date: Tue, 06 May 2008 08:52:20 +0200

Hi dan, all,

|   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.

Well, I wondered myself if my choice of word was good. In fact, I was
not refering to political as in: laws, jurisdiction, courts, prime
ministers, presidents... but as in non-technical, managerial,
financial-driven, contractual-driven etc.

|   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).

To elaborate on what my notion "political" in our scenario concretely
means, here an example: the eduroam community is primarily intended for
higher education and research, which excludes secondary school pupils.
Some countries however deploy eduroam in such schools, and hand out
accounts which work internationally for their teachers, but only
nationally valid accounts for the pupils in order not violate
international peering agreements but still give service to the pupils.

That is perfectly fine with eduroam international, as long as these
countries can make sure these local accounts stay local. The means to
enforce this is in practice by using a national proxy which knows which
realms belong to pupil database backends and which not. That is IIRC the
main reason for the one country that insists on having everything go
through its national proxy.

We recently have overcome this by loosening the peering agreement so
that everyone considered a valid user in one country is also valid for
roaming in all others, but this now re-opens the age verification
problem at a larger scale :-/

Greetings,

Stefan

---

From: Klaas Wierenga <[email-masked]>
Date: Tue, 06 May 2008 10:57:46 +0200

Stefan Winter wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi dan, all,
> 

I guess you could say that the proxy's are a policy enforcement point...

Klaas

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 6 May 2008 08:28:19 -0700

Klaas Wierenga <[email-masked]> scribbled on Tuesday, May 06, 2008
1:58 AM:

...

> I guess you could say that the proxy's are a policy enforcement

I suppose you could, but I wish you wouldn't ;-).

...

---

From: Klaas Wierenga <[email-masked]>
Date: Tue, 06 May 2008 20:07:57 +0200

Glen,

> I suppose you could, but I wish you wouldn't ;-).

;-)

but that is what it does, doesn't it? It either or not forwards 
authentication requests based on the forwarding policies that have been 
set.... The point I wanted to make is that the proxy in this case is 
about policies, not about politics.

Klaas

---

From: Stefan Winter <[email-masked]>
Date: Tue, 06 May 2008 21:36:54 +0200

Hi,
> authentication requests based on the forwarding policies that have 
> been set.... The point I wanted to make is that the proxy in this case 
> is about policies, not about politics.

Well concept is correct, but the term of policy enforcement point is a 
bit problematic these days, because it is used in a different context 
and with a different meaning already: NEA. In NEA, the PEP has 
approximately the role of a NAS. While what we are talking about here is 
not about stuff that happens on a NAS, but on a AAA server behind that 
NAS. So, if we were to use terms from the NEA world, I would rather say 
that a policy-driven proxy should be termed Policy Decision Point - 
after all, forwarding-or-not is a decision, not an enforcement. Anyway, 
thanks for the pointer in the general NEA direction - a NEA PDP is 
indeed quite an analogous thing to a AAA policy-motivated proxy IMHO.

Enough acronyms for a day,

Stefan

---

From: Klaas Wierenga <[email-masked]>
Date: Tue, 06 May 2008 22:48:19 +0200

> indeed quite an analogous thing to a AAA policy-motivated proxy IMHO.

I agree that the terminology is a bit awkward, but I DID mean PEP 
instead of PDP, funny enough the AAA server, in the case of a proxy 
RADIUS DOES serve as the PEP (and I guess as well as PDP), and we ARE 
talking here about the stuff that is happening on a NAS: deny or approve 
traffic (in this case authentication requests)....

Klaas