[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
- [proxies] [IETF Proxy] Minutes of Proxy Meeting i… Katrin Hoeper