Re: [proxies] [IETF Proxy] Next Steps

proxies-bounces@ietf.org <> 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. 
> 
> 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. 

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.

...
_______________________________________________
Proxies mailing list
Proxies@ietf.org
https://www.ietf.org/mailman/listinfo/proxies