Re: [proxies] [IETF Proxy] Next Steps

"Glen Zorn" <gzorn@arubanetworks.com> Sat, 19 April 2008 07:00 UTC

Return-Path: <proxies-bounces@ietf.org>
X-Original-To: proxies-archive@ietf.org
Delivered-To: ietfarch-proxies-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C48FE3A6A61; Sat, 19 Apr 2008 00:00:04 -0700 (PDT)
X-Original-To: proxies@core3.amsl.com
Delivered-To: proxies@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBB3E3A6A61 for <proxies@core3.amsl.com>; Sat, 19 Apr 2008 00:00:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyM3mnliz2ei for <proxies@core3.amsl.com>; Sat, 19 Apr 2008 00:00:02 -0700 (PDT)
Received: from mail.arubanetworks.com (mail.arubanetworks.com [216.31.249.253]) by core3.amsl.com (Postfix) with SMTP id A88DE28C309 for <proxies@ietf.org>; Sat, 19 Apr 2008 00:00:02 -0700 (PDT)
Received: from aruba-mx1.arubanetworks.com ([10.1.1.17]) by mail.arubanetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 19 Apr 2008 00:00:03 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 18 Apr 2008 23:59:56 -0700
Message-ID: <A3DA4C2546E1614D8ACC896746CDCF29011A353E@aruba-mx1.arubanetworks.com>
In-Reply-To: <200804180911.39758.stefan.winter@restena.lu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [proxies] [IETF Proxy] Next Steps
Thread-Index: AcihI30MS7v3o50hScCto/fzBMsYjQAxnWQQ
References: <7.0.1.0.2.20080416172531.02401228@nist.gov><200804171550.48931.stefan.winter@restena.lu><480769A1.9080408@nitros9.org> <200804180911.39758.stefan.winter@restena.lu>
From: "Glen Zorn" <gzorn@arubanetworks.com>
To: "Stefan Winter" <stefan.winter@restena.lu>
X-OriginalArrivalTime: 19 Apr 2008 07:00:03.0808 (UTC) FILETIME=[FE216600:01C8A1EA]
Cc: proxies@ietf.org
Subject: Re: [proxies] [IETF Proxy] Next Steps
X-BeenThere: proxies@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion list for ad hoc group interested in security and proxies <proxies.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/proxies>, <mailto:proxies-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:proxies@ietf.org>
List-Help: <mailto:proxies-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/proxies>, <mailto:proxies-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: proxies-bounces@ietf.org
Errors-To: proxies-bounces@ietf.org

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