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