Re: [proxies] [IETF Proxy] Next Steps

<Bernard_Aboba@hotmail.com> Sat, 03 May 2008 06:07 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 9F2393A6A36; Fri, 2 May 2008 23:07:43 -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 2C2EE3A69C1 for <proxies@core3.amsl.com>; Fri, 2 May 2008 23:07:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.066
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDyFnMqxMoSr for <proxies@core3.amsl.com>; Fri, 2 May 2008 23:07:42 -0700 (PDT)
Received: from blu0-omc2-s21.blu0.hotmail.com (blu0-omc2-s21.blu0.hotmail.com [65.55.111.96]) by core3.amsl.com (Postfix) with ESMTP id 5AE453A68CB for <proxies@ietf.org>; Fri, 2 May 2008 23:07:42 -0700 (PDT)
Received: from BLU137-DS6 ([65.55.111.73]) by blu0-omc2-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 May 2008 23:07:43 -0700
X-Originating-IP: [24.18.147.115]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU137-DS6C89AAEC0FCF9AC99747E93D50@phx.gbl>
From: Bernard_Aboba@hotmail.com
In-Reply-To: <7.0.1.0.2.20080416172531.02401228@nist.gov><200804171550.48931.stefan.winter@restena.lu> <273c5c8bff26c3c057519da2b038e1ba.squirrel@www.trepanning.net>
To: Dan Harkins <dharkins@lounge.org>, Stefan Winter <stefan.winter@restena.lu>
References: <7.0.1.0.2.20080416172531.02401228@nist.gov><200804171550.48931.stefan.winter@restena.lu> <273c5c8bff26c3c057519da2b038e1ba.squirrel@www.trepanning.net>
X-Unsent: 1
Date: Fri, 02 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]
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

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

>  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
Proxies@ietf.org
https://www.ietf.org/mailman/listinfo/proxies