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

Bernard Aboba <bernard_aboba@hotmail.com> Sun, 16 November 2008 14:42 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 9A22D3A681D; Sun, 16 Nov 2008 06:42:50 -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 44AD63A681D for <proxies@core3.amsl.com>; Sun, 16 Nov 2008 06:42:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.27
X-Spam-Level:
X-Spam-Status: No, score=-1.27 tagged_above=-999 required=5 tests=[AWL=1.328, 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 xUN8tnRAGk0j for <proxies@core3.amsl.com>; Sun, 16 Nov 2008 06:42:48 -0800 (PST)
Received: from blu0-omc1-s28.blu0.hotmail.com (blu0-omc1-s28.blu0.hotmail.com [65.55.116.39]) by core3.amsl.com (Postfix) with ESMTP id 319E13A67AD for <proxies@ietf.org>; Sun, 16 Nov 2008 06:42:48 -0800 (PST)
Received: from BLU137-W54 ([65.55.116.8]) by blu0-omc1-s28.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 16 Nov 2008 06:42:47 -0800
Message-ID: <BLU137-W5423E91D195604613D259C93100@phx.gbl>
X-Originating-IP: [71.222.81.45]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: <klaas@wierenga.net>
Date: Sun, 16 Nov 2008 06:42:47 -0800
Importance: Normal
In-Reply-To: <491FE573.4060505@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> <BLU137-W184088AF25C88B75E1D78593110@phx.gbl> <491FE573.4060505@wierenga.net>
MIME-Version: 1.0
X-OriginalArrivalTime: 16 Nov 2008 14:42:47.0863 (UTC) FILETIME=[97F53C70:01C947F9]
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="===============0959486993=="
Sender: proxies-bounces@ietf.org
Errors-To: proxies-bounces@ietf.org

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

The document doesn't cite some existing threat model assessments,
including RFC 5247 which is standards track and was chartered for
this purpose.  So I'd say that a new threat model document (if it
is needed) should focus on what is missing or what has 
changed with respect to those prior assessments.

One thing that has changed is RADSEC.  RADSEC challenges may of the 
assumptions that have been made relating to RADIUS, such as:

         RADIUS clients and servers cannot support certificates
         RADIUS cannot support confidentiality
         RADIUS requires a "trapezoid" model similar to SIP
         RADIUS clients cannot handle DNS lookups
         Proxy-avoidance technologies such as Diameter "redirect" cannot be deployed
         Large scale roaming between many domains is very difficult to set up
         
Once these assumptions become invalid, many of the security threats/issues also
disappear, and new ones may appear in their place.  In particular, given that
EDUROAM is virtually the only large scale deployed instance of inter-domain key 
transport, it probably makes sense to focus on it, rather than analyzing the 
security risks of other (nonexistent) deployments such as WiMAX. 

For example, if we start with the analysis of the operational benefits

of proxies described in RFC 2607, we find that several of the benefits
don't exist with RADSEC:
1.   Scalability improvement
2,   Authentication forwarding
3.   Capabilities adjustment
4.   Policy implementation
5.   Accounting reliability improvement
6.   Atomic operation

Of these benefits, at least #1 and #2 is no longer 
required with RADSEC using certificates.  Do benefits
#3, 4, 5 or 6 occur in a network such as EDUROAM?

_______________________________________________
Proxies mailing list
Proxies@ietf.org
https://www.ietf.org/mailman/listinfo/proxies