Re: [proxies] [IETF Proxy] Next Steps

<> Sat, 03 May 2008 06:07 UTC

Return-Path: <>
Received: from (localhost []) by (Postfix) with ESMTP id 9F2393A6A36; Fri, 2 May 2008 23:07:43 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C2EE3A69C1 for <>; Fri, 2 May 2008 23:07:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.066
X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, SARE_HEAD_XUNSENT=1.666, STOX_REPLY_TYPE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XDyFnMqxMoSr for <>; Fri, 2 May 2008 23:07:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5AE453A68CB for <>; Fri, 2 May 2008 23:07:42 -0700 (PDT)
Received: from BLU137-DS6 ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 May 2008 23:07:43 -0700
X-Originating-IP: []
X-Originating-Email: []
Message-ID: <BLU137-DS6C89AAEC0FCF9AC99747E93D50@phx.gbl>
From: <>
In-Reply-To: <><> <>
To: "Dan Harkins" <>, "Stefan Winter" <>
References: <><> <>
X-Unsent: 1
Date: Fri, 2 May 2008 23:08:01 -0700
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 12.0.1606
X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606
X-OriginalArrivalTime: 03 May 2008 06:07:43.0944 (UTC) FILETIME=[0068AC80:01C8ACE4]
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

>  These are not things that I think we _have_ to deal with especially in
> a technical forum.

I would agree.   In years of previous discussion, including published
RFCs dealing with the proxy threat model, the assumption has always
been that the IETF's goal is to enable the deployment of secure systems.
The goal of enabling surveillance, information gathering, or unlawful
intercept has not previously been a goal.

The point of this is I think, that one cannot have a rational discussion
of security measures, if in fact, the goal is actually to enable backdoors.
A system that is engineered to provide a backdoor will inevitably
(surprise!) be found to have a security vulnerability.

So I think we need to be very explicit about what we are trying to
achieve -- and also, we need to be very clear about the actual
extent of the problem today.

>  I have heard many other reasons why AAA proxies must exist.

The functions of proxies are described in some detail in RFC 2607, Section 

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

It is also possible that proxies can allow service that might otherwise be
denied (even though this is forbidden by RFC 2607 Section 5.1).   However,
as described in RFC 2607 Section 5.2, the implementation of "policy"
typically applies to authentication/authorization, but not to accounting. 

Proxies mailing list