Re: [proxies] [IETF Proxy] Next Steps

"Glen Zorn" <> Sat, 19 April 2008 07:00 UTC

Return-Path: <>
Received: from (localhost []) by (Postfix) with ESMTP id C48FE3A6A61; Sat, 19 Apr 2008 00:00:04 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id CBB3E3A6A61 for <>; Sat, 19 Apr 2008 00:00:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QyM3mnliz2ei for <>; Sat, 19 Apr 2008 00:00:02 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id A88DE28C309 for <>; Sat, 19 Apr 2008 00:00:02 -0700 (PDT)
Received: from ([]) by 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: <>
In-Reply-To: <>
Thread-Topic: [proxies] [IETF Proxy] Next Steps
Thread-Index: AcihI30MS7v3o50hScCto/fzBMsYjQAxnWQQ
References: <><><> <>
From: "Glen Zorn" <>
To: "Stefan Winter" <>
X-OriginalArrivalTime: 19 Apr 2008 07:00:03.0808 (UTC) FILETIME=[FE216600:01C8A1EA]
Subject: Re: [proxies] [IETF Proxy] Next Steps
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion list for ad hoc group interested in security and proxies <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: <> 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"

Proxies mailing list