Re: [proxies] [IETF Proxy] Next Steps

[Stefan Winter <[e-mail]>]

Hi,

> > So if a foreign eduroam user authenticates within Australia, the visited
> > 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.

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

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

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.

> > - proxies can intercept data they are not entitled for and abuse it
>
>   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.

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

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

Certainly!

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