Re: [proxies] Review of draft-hoeper-proxythreat-01.txt (Part 1)
Bernard Aboba <bernard_aboba@hotmail.com> Sat, 15 November 2008 20:51 UTC
Return-Path: <proxies-bounces@ietf.org>
X-Original-To: proxies-archive@ietf.org
Delivered-To: ietfarch-proxies-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC2D23A6887; Sat, 15 Nov 2008 12:51:45 -0800 (PST)
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 7B6073A6887 for <proxies@core3.amsl.com>; Sat, 15 Nov 2008 12:51:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.747
X-Spam-Level:
X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[AWL=0.851, BAYES_00=-2.599, HTML_MESSAGE=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 r3v2WWoXYF1P for <proxies@core3.amsl.com>; Sat, 15 Nov 2008 12:51:43 -0800 (PST)
Received: from blu0-omc1-s38.blu0.hotmail.com (blu0-omc1-s38.blu0.hotmail.com [65.55.116.49]) by core3.amsl.com (Postfix) with ESMTP id 361913A6834 for <proxies@ietf.org>; Sat, 15 Nov 2008 12:51:43 -0800 (PST)
Received: from BLU137-W18 ([65.55.116.7]) by blu0-omc1-s38.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 15 Nov 2008 12:51:43 -0800
Message-ID: <BLU137-W184088AF25C88B75E1D78593110@phx.gbl>
X-Originating-IP: [71.222.81.45]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: klaas@wierenga.net, Stefan Winter <stefan.winter@restena.lu>
Date: Sat, 15 Nov 2008 12:51:43 -0800
Importance: Normal
In-Reply-To: <491EBDA2.4060209@wierenga.net>
References: <7.0.1.0.2.20081104092258.0251aaa0@nist.gov> <7.0.1.0.2.20081104105518.025aa8c8@nist.gov> <BLU137-W54E3AB48E6D604B591851E931F0@phx.gbl> <491D92DF.6020100@restena.lu> <491EBDA2.4060209@wierenga.net>
MIME-Version: 1.0
X-OriginalArrivalTime: 15 Nov 2008 20:51:43.0011 (UTC) FILETIME=[F71F0730:01C94763]
Cc: proxies@ietf.org, katrin.hoeper@nist.gov
Subject: Re: [proxies] Review of draft-hoeper-proxythreat-01.txt (Part 1)
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-Archive: <https://www.ietf.org/mailman/private/proxies>
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="===============0776534015=="
Sender: proxies-bounces@ietf.org
Errors-To: proxies-bounces@ietf.org
> I am not very much in favor of mixing security considerations with> operational considerations of proxies. It is my understanding that these> are of a different nature. I would prefer to work from the assumption in> this document that we stay out of any debate about whether proxies are a> good or a bad thing but rather take it as a given and analyse the> security and privacy threats that result. The point is that the IETF has been working on this problem for a long time already. Multiple areas within the IETF have had major issues with proxies, and in toto, there are probably several hundred pages of threat analyses and proposals (some implemented, some not). Many of the issues encountered by different areas are very similar (e.g. the discussion relating to SRTP keying in SDP is not very different from the discussion of key transport in AAA). Given this extensive body of work, the question is how to move forward. One of the things we learned from the NAT debate was that it was critical to develop a detailed understanding of how NATs deployed in the field actually behaved. In many cases the actual behavior was more complex and variable that we had believed originally. Similarly, I believe that understanding how proxies are actually deployed and used is critical. For example, at present inter-domain key transport via proxies is very rarely deployed (EDUROAM is the only major deployment I am aware of). This is because 802.11i has not caught on in hospitality, hotspots or carriers, where web portals are overwhelmingly popular. In enterprise, where 802.11i has caught on, but there is not much interest in inter-domain key transport, probably because most of the local access networks don't support IEEE 802.11i. Aside from IEEE 802.11, the major wireless technology that has contemplated use of EAP keying along with AAA roaming is WiMAX. However, WMF v1.0 roaming support is weak (there is no mandatory-to-implement user authentication mechanism), so that most of the initial deployments don't support roaming. In addition, wholesaling is also not well supported (AAA servers need to obtain a certificate from the WMF, at considerable cost). As a result, there is not much chance that inter-domain key transport will be deployed for WiMAX in the near future. Some similar observations can be made relating to the deployment of inter-domain SIP with SRTP. Neither SIP inter-domain use nor SRTP support are common today, and the intersection of the two is virtually non-existent. So while end-to-end security might seem like a useful goal, in practice there is not much movement toward that in evidence. It's barely possible to even purchase a handset with minimal SRTP (e.g. RFC 3711) support today. My takeaway from all this is that real world deployments appear to have a very low complexity tolerance. Even technologies which are frequently assumed to be well established (e.g. EAP, 802.1X) frequently exceed that tolerance level. > An operational considerations document would be a welcome separate> document, but let's not mix these two. In a way the latter document to> some extent will explain how the security threats can be overcome (in> addition to other operational considerations). The IETF has already produced lots of documents relating to "solutions" to the proxy security problem. The AAA WG alone spent 5 years on this, producing three different proposals, two of which have actually been implemented (e.g. Diameter Redirect and AAA/Kerberos integration). So neither a problem analysis nor proposed solutions are new.
_______________________________________________ Proxies mailing list Proxies@ietf.org https://www.ietf.org/mailman/listinfo/proxies
- [proxies] New draft: draft-hoeper-proxythreat-01.… Katrin Hoeper
- Re: [proxies] New draft: draft-hoeper-proxythreat… Katrin Hoeper
- [proxies] Review of draft-hoeper-proxythreat-01.t… Bernard Aboba
- Re: [proxies] Review of draft-hoeper-proxythreat-… Stefan Winter
- Re: [proxies] Review of draft-hoeper-proxythreat-… Katrin Hoeper
- Re: [proxies] Review of draft-hoeper-proxythreat-… Klaas Wierenga
- Re: [proxies] Review of draft-hoeper-proxythreat-… Bernard Aboba
- Re: [proxies] Review of draft-hoeper-proxythreat-… Klaas Wierenga
- Re: [proxies] Review of draft-hoeper-proxythreat-… Bernard Aboba
- Re: [proxies] Review of draft-hoeper-proxythreat-… Alan DeKok
- [proxies] next steps for draft-hoeper-proxythreat… Klaas Wierenga