Subject: [proxies] [IETF Proxy] Next Steps

From: Katrin Hoeper <[email-masked]>
Date: Wed, 16 Apr 2008 17:45:27 -0400

Hey everybody,

Instead of continuing our heated debate from Philadelphia, I propose 
to choose a more directed & organized path [fill in jokes about 
Germans] for our future proxy discussions on this list.

Before we start proposing and analyzing solutions, we first need to 
evaluate if the IETF should propose a solution for problems 
introduced by proxies. If we come to the conclusion "NO", the IETF 
shouldn't (because there aren't any problems, or the problems are not 
severe enough for network providers to demand such a solution), we 
should still document and publish these results to provide a 
reference for other IETF documents and to stop the never ending proxy 
discussions that slow down so many WGs. If we come to the conclusion 
"YES", the IETF should do something, it seems to be a good idea to 
have a BOF or pick an existing WG to continue working on the 
identified "proxy problems".

I propose the following next steps for our "proxy group" before IETF 
72 in Dublin:

  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

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?

3. Analyze the feasibility and severity of the identified threats

After these steps are completed, we should be able to decide whether 
we should continue.
I volunteer to serve as an editor for a draft covering the results of 
our initial investigation.

Please post your comments to the list. Feel free to use my ppt slides 
from Philadelphia as basis for your comments, but please focus on the 
outlined initial steps in this message.

Especially steps 1 and 3 require input from network providers and 
other hands-on people who actually work with proxy networks. We need 
your feedback!

Best regards,
Katrin

----------
Katrin Hoeper
Computer Security Division
National Institute of Standards and Technology (NIST)
100 Bureau Dr. Mail stop: 8930
Gaithersburg, MD 20878
(301) 975 - 4024
_______________________________________________
Proxies mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/proxies

---

From: Stefan Winter <[email-masked]>
Date: Thu, 17 Apr 2008 15:50:43 +0200

Hello,

> 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 ;-) ]

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

> 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

---

From: Alan DeKok <[email-masked]>
Date: Thu, 17 Apr 2008 17:15:45 +0200

Stefan Winter wrote:
> domain needs to get information about the age of the user.

  IANAL, but there are adults who are not legally responsible for their
actions.  Requiring that the users be "legally responsible" may satisfy
the constraint, while exposing minimal information.

> Without proxies, 
> identifiable data sets.

  It gets worse than that.  How does one end express a query that the
other end can understand?  This involves defining a fairly complex
policy language.  So far, all attempts to define a usable policy
language have failed.

> - proxies can intercept data they are not entitled for and abuse it

  Yes.  Non-technical means exist to address this problem.

> want to make a blanket statement here.

  The people I talk to indicate that they are more worried about users
abusing the system than insiders.

  e.g. wireless sniffers at a hotspot are a problem.  Malicious proxies
aren't.

  I do think we need a documentation explaining the possible
architectures, the threats, requirements, and judged risks.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Fri, 18 Apr 2008 09:11:35 +0200

Hi,

> the constraint, while exposing minimal information.

I am very happy that I didn't have to dig into the gory details of the issue 
yet. My first shot at it is: if that adult isn't legally responsive for his 
actions, he's very likely not a member of the higher ed and research 
community, so the number of occurences in our constituency is very likely to 
be 0 :-)

> > communicate the value. With proxies, things are worse: the traffic will
> > be sent through intermediate proxy servers, which can then correlate the

I guess it's not so important in the scope of this list, but here goes a short 
overview of something we made up to overcome these things.

First there is the SAML language that allows to query attributes about a user. 
It includes a user consent part (his "attribute release policy"). SAML 
entities can communicate their attribute payload without using proxies.

There is also a common schema for user attributes in the educational 
community: MACE's eduPerson schema, and a few extensions to that in SCHAC, 
the Schema for Academia. These are used to express user attributes in SAML. 
They are roughly unambiguous in their content.

The current approach in our labs is: use a RADIUS attribute to send a short 
SAML authentication artifact plus a URL of a responsible SAML 
attribute-source via the proxy chain from home domain to visited domain along 
with the RADIUS Accept.
Visited domain can use this opaque handle to request user attributes directly 
from the home domain's SAML attribute-source.
Of course, every proxy has access to the same artifact and URL. Here the 
user's attribute release policy is supposed to come to the rescue: he must 
have specified beforehand that the specific visited domain is allowed to ask 
for the attribute in question. Other proxies will not have the user's consent 
and don't get any attributes.

Needless to say: this is complicated. We have a prototype of this, but frankly 
I think it is best described with the words "weird" and "whacky". I don't see 
this going into production any time soon.

>   Yes.  Non-technical means exist to address this problem.

Certainly. Contractual bounds could be used. My personal preference would be 
to have an encryption channel between home and visited domain AAA servers 
(_not_ NASes) to eliminate the problem of paperwork at all, but I admit that 
this is almost impossible to do correct.

>   e.g. wireless sniffers at a hotspot are a problem.  Malicious proxies

I'd like to remind that we had entertaining discussions about people being 
worried of proxies inserting faked accounting packets. I'm not sure to what 
extent operators care about that though. FWIW, our own community doesn't care 
so much: it's a free service. :-)

> architectures, the threats, requirements, and judged risks.

Certainly!

Greetings,

Stefan Winter

-- 
Stefan WINTER

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 18 Apr 2008 23:59:56 -0700

[email-masked] <> scribbled on Friday, April 18, 2008 2:12 PM:

...
 
> I guess it's not so important in the scope of this list, but
> here goes a short overview of something we made up to overcome these
> things. 
> 
> It includes a user consent part (his "attribute release
> policy"). SAML entities can communicate their attribute
> payload without using proxies.
> 
> community: MACE's eduPerson schema, and a few extensions to
> that in SCHAC, the Schema for Academia. These are used to
> express user attributes in SAML.
> The current approach in our labs is: use a RADIUS attribute to
> send a short SAML authentication artifact plus a URL of a
> responsible SAML attribute-source via the proxy chain from
> home domain to visited domain along with the RADIUS Accept.
> Visited domain can use this opaque handle to request user
> attributes directly from the home domain's SAML attribute-source.
> Of course, every proxy has access to the same artifact and
> URL. Here the user's attribute release policy is supposed to
> come to the rescue: he must have specified beforehand that the
> specific visited domain is allowed to ask for the attribute in
> question. Other proxies will not have the user's consent and
> don't get any attributes.
> 
> Needless to say: this is complicated. We have a prototype of
> this, but frankly I think it is best described with the words
> "weird" and "whacky". I don't see this going into production
> any time soon.
> 
> Certainly. Contractual bounds could be used. My personal
> preference would be to have an encryption channel between home
> and visited domain AAA servers (_not_ NASes) to eliminate the
> problem of paperwork at all, but I admit that this is almost
> impossible to do correct. 

Not sure why you say this: getting the keys set up might be politically
or procedurally hard, but it seems technically straightforward.  

> 
>>> - 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.
>> 
>>   The people I talk to indicate that they are more worried about
>> users abusing the system than insiders.
>> 
>>   e.g. wireless sniffers at a hotspot are a problem.  Malicious
>> proxies aren't.
> 
> I'd like to remind that we had entertaining discussions about
> people being worried of proxies inserting faked accounting
> packets. I'm not sure to what extent operators care about that
> though. FWIW, our own community doesn't care so much: it's a
> free service. :-)

Of course, this is a general problem w/RADIUS, but it could be solved
using the same techniques used for the problem of "encryption channel"
above.

...

---

From: Stefan Winter <[email-masked]>
Date: Tue, 22 Apr 2008 08:09:58 +0200

|> Certainly. Contractual bounds could be used. My personal
|> preference would be to have an encryption channel between home
|> and visited domain AAA servers (_not_ NASes) to eliminate the
|> problem of paperwork at all, but I admit that this is almost
|> impossible to do correct.
|
| Not sure why you say this: getting the keys set up might be politically
| or procedurally hard, but it seems technically straightforward.

I assume you are thinking of a manual key distribution between peers?
That is an option for a small scale deployment for sure. With 1000 admin
domains where every one may want to exchange secret information with
everyone else, there would need to be 1000^2 sets of keys in place. All
peers are not allowed to be in possession of any keys but those
concerning themselves. While it is technically possible (maybe), the
deployment and maintenance hurdles of such a key blob are prohibitive.

Or did you mean something completely different that we simply
overlooked? I'd be very eager to hear about it then!

Greetings,

Stefan Winter

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 22 Apr 2008 00:00:42 -0700

Stefan Winter <mailto:[email-masked]> scribbled on Tuesday,
April 22, 2008 1:10 PM:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
>>> Certainly. Contractual bounds could be used. My personal preference
>>> would be to have an encryption channel between home and visited
>>> domain AAA servers (_not_ NASes) to eliminate the problem of
>>> paperwork at all, but I admit that this is almost impossible to do
>>> correct.
>> 
>> Not sure why you say this: getting the keys set up might be
>> politically or procedurally hard, but it seems technically
>> straightforward. 
> 
> That is an option for a small scale deployment for sure. With
> 1000 admin domains where every one may want to exchange secret
> information with everyone else, there would need to be 1000^2
> sets of keys in place. All peers are not allowed to be in
> possession of any keys but those concerning themselves. While
> it is technically possible (maybe), the deployment and
> maintenance hurdles of such a key blob are prohibitive.
> 

Sorry, the "it" to which I was referring is the encrypted channel, not
the key distribution.  Key distribution seems always to be hard, whether
manual or "automatic"...

...