Re: [proxies] [IETF Proxy] Next Steps

"Glen Zorn" <> Sat, 03 May 2008 20:55 UTC

Return-Path: <>
Received: from (localhost []) by (Postfix) with ESMTP id 054653A6BE0; Sat, 3 May 2008 13:55:48 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 456CC3A6BE0 for <>; Sat, 3 May 2008 13:55:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VvQz-TfqtGsA for <>; Sat, 3 May 2008 13:55:46 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 763183A6BB1 for <>; Sat, 3 May 2008 13:55:46 -0700 (PDT)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Sat, 3 May 2008 13:55:47 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sat, 3 May 2008 13:55:47 -0700
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [proxies] [IETF Proxy] Next Steps
Thread-Index: AcisqTZC5zj/O/AtQoejWTVqsH95kQAs/tSQ
References: <><> <>
From: "Glen Zorn" <>
To: "Dan Harkins" <>, "Stefan Winter" <>
X-OriginalArrivalTime: 03 May 2008 20:55:47.0998 (UTC) FILETIME=[102E13E0:01C8AD60]
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, May 02, 2008 4:07 PM:

>  Hi Stefan,
> On Thu, April 17, 2008 6:50 am, Stefan Winter wrote:
> [snip]
>> 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.
>  This political proxy thing concerns me. The only traffic
> that a AAA proxy could inspect, control or modify is AAA
> traffic. So what this entity would do is glean information
> about who is using what network where and, in some cases,
> prevent some people somewhere from using some network.
>  These are not things that I think we _have_ to deal with
> especially in a technical forum. These are issues that a
> customer will require a vendor of AAA product to support, in
> much the same way that "lawful intercept"
> is a political add-on to a technical solution-- e.g. the IPsec
> WG did not architect "lawful intercept" into RFC2401 but
> people that have implemented IPsec have added backdoors into
> their products to allow for it. 

If the "security gateway" is not an architected listening post, what is

> I'm sure that some RFP
> somewhere will mandate, if it doesn't already, that
> evesdropping and controlling entities be required in between
> AAA client and AAA server but that isn't really the
> problemspace we're dealing with.

Things aren't quite as sinister as you seem to imagine, Dan.  Attributes
may be added or removed for perfectly valid operational reasons; that is
exactly the problemspace with which we're dealing.  It's not always
either possible or appropriate for the home AAA server to be aware of
the correct parameters to be supplied to a visited NAS, for example...

>  I have heard many other reasons why AAA proxies must exist.
> If a magic wand made all those reasons disappear I really hope
> this political justification would not keep them around.
> (Note: I'm not entertaining the notion of getting rid of
> proxies, just theorizing, so don't attack me).
>  This does highlight threats though. It's not just that
> proxies can listen to AAA exchanges, they can glean
> information out of AAA exchanges, and they can constrain or
> deny service that should otherwise be unconstrained or allowed.

Hmm.  Substitute "would" for "should" & it seems to me that you have
just restated a definition of the term "authorization".
Proxies mailing list