[proxies] [IETF Proxy] Minutes of Proxy Meeting in Philadelphia at IETF 71

Katrin Hoeper <katrin.hoeper@nist.gov> Wed, 16 April 2008 21:32 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 E13513A6CCC; Wed, 16 Apr 2008 14:32:51 -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 ADD103A6A47 for <proxies@core3.amsl.com>; Wed, 16 Apr 2008 14:26:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 bWVXJp9qMW0k for <proxies@core3.amsl.com>; Wed, 16 Apr 2008 14:26:41 -0700 (PDT)
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by core3.amsl.com (Postfix) with ESMTP id 90C303A696C for <proxies@ietf.org>; Wed, 16 Apr 2008 14:26:41 -0700 (PDT)
Received: from mesico.nist.gov (csme13.ncsl.nist.gov [129.6.54.47]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m3GLPBGv013494 for <proxies@ietf.org>; Wed, 16 Apr 2008 17:27:11 -0400
Message-Id: <7.0.1.0.2.20080416171927.0242ee68@nist.gov>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Wed, 16 Apr 2008 17:25:11 -0400
To: proxies@ietf.org
From: Katrin Hoeper <katrin.hoeper@nist.gov>
Mime-Version: 1.0
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: katrin.hoeper@nist.gov
X-Mailman-Approved-At: Wed, 16 Apr 2008 14:32:50 -0700
Subject: [proxies] [IETF Proxy] Minutes of Proxy Meeting in Philadelphia at IETF 71
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: multipart/mixed; boundary="===============1513854435=="
Sender: proxies-bounces@ietf.org
Errors-To: proxies-bounces@ietf.org

Hey everybody,

Let's get this proxy list started with brief summary of our informal 
"Proxy meeting" in Philadelphia at IETF 71 (list of attendees at the end).

There was a lot of disagreement, but let's start with the few 
fundamental things we seemed to agree on:

1. There is large interest in discussing proxy-related problems in 
several IETF WGs. The attendance at the kick-off meeting is proof for that.

2. We cannot ignore proxies because they are widely deployed and used 
today. It is unlikely that this will change in the future. Hence, we 
must "live" with proxies.

3. Currently there are not many known attacks or recorded attacks 
exploiting proxies. However, this may change in the future due to 
increasing deployments and new applications.

4. Summarizing the three previous points, we all agreed that 
"something" should be done.

Disagreements started, when we tried to explore WHAT should be done. 
Here some of the questions that came up during the meeting that 
couldn't find any consensus (yet):

    * What applications do we need to consider?
-       where & how are proxies used today?
-       where & how will they be used in the future?
-       what are typical network architectures?

    * How do proxies affect the security of network protocols?
-       how does the trust model change by introducing proxies?
-       are all existing and potential future protocols affected in 
the same way, allowing for a universal solution?

    * How can proxies exploit their keys?
-       what type of keys/information do proxies (must) have access to?
-       what attacks can proxies launch with these keys?

    * Independent of key knowledge, proxies can always analyze the 
network traffic
-       is this problem proxy specific?
-       is traffic analysis considered a serious attack?
-       are there other threats that do not require knowledge of key material?

    * Potential solutions (?)
-       is end-to-end security between peer and authentication server 
THE answer to all problems?
-       or end-to-end security between NAS and server?
-       & anonymous/pseudonymous communications to prevent traffic analysis?
-       above solutions already exist, why are they not 
used/deployed? No demand, not practical or not a solution to (all) problem(s)?

Best regards,

Katrin

Attendees of kick-off meeting in Philadelphia at IETF 71:
Tim Polk
Katrin Hoeper
Charles Clancy
Pasi Eronen
Dan Harkins
Glen Zorn
Klaas Wierenga
Stefan Winter
Joe Saloway
Russ Housley
Sam Hartmann
Mark Jones
Jouni Korhonen
Avi Lior,
Hannes Tschofenig



----------
Katrin Hoeper
Computer Security Division
National Institute of Standards and Technology (NIST)
100 Bureau Dr. Mail stop: 8930
Gaithersburg, MD 20878
(301) 975 - 4024
_______________________________________________
Proxies mailing list
Proxies@ietf.org
https://www.ietf.org/mailman/listinfo/proxies