Re: [proxies] Review of draft-hoeper-proxythreat-01.txt (Part 1)

Klaas Wierenga <> Sun, 16 November 2008 09:18 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id F1C123A684B; Sun, 16 Nov 2008 01:18:51 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 451533A684B for <>; Sun, 16 Nov 2008 01:18:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YOFJiZL6jpuY for <>; Sun, 16 Nov 2008 01:18:50 -0800 (PST)
Received: from ( [IPv6:2001:610:508:110:192:87:110:29]) by (Postfix) with ESMTP id 31CEE3A6805 for <>; Sun, 16 Nov 2008 01:18:50 -0800 (PST)
Received: from ([] by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <>) id 1L1dmG-000C3T-O2; Sun, 16 Nov 2008 10:18:44 +0100
Message-ID: <>
Date: Sun, 16 Nov 2008 10:18:43 +0100
From: Klaas Wierenga <>
User-Agent: Thunderbird (Macintosh/20080914)
MIME-Version: 1.0
To: Bernard Aboba <>
References: <> <> <BLU137-W54E3AB48E6D604B591851E931F0@phx.gbl> <> <> <BLU137-W184088AF25C88B75E1D78593110@phx.gbl>
In-Reply-To: <BLU137-W184088AF25C88B75E1D78593110@phx.gbl>
X-Antivirus: no malware found
Subject: Re: [proxies] Review of draft-hoeper-proxythreat-01.txt (Part 1)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion list for ad hoc group interested in security and proxies <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

Bernard Aboba wrote:


Fair points, but aren't you than essentially saying "forget about the 
threats and write *only* a deployment draft"?


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