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