Re: [Rserpool] security review of enrp, asap, et al
Lars Eggert <lars.eggert@nokia.com> Mon, 23 June 2008 07:05 UTC
Return-Path: <rserpool-bounces@ietf.org>
X-Original-To: rserpool-archive@megatron.ietf.org
Delivered-To: ietfarch-rserpool-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7DDD3A690A; Mon, 23 Jun 2008 00:05:37 -0700 (PDT)
X-Original-To: rserpool@core3.amsl.com
Delivered-To: rserpool@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E010E3A690A for <rserpool@core3.amsl.com>; Mon, 23 Jun 2008 00:05:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.2
X-Spam-Level:
X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799]
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 XgwS+zuilHiw for <rserpool@core3.amsl.com>; Mon, 23 Jun 2008 00:05:36 -0700 (PDT)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 9EABC3A68C7 for <rserpool@ietf.org>; Mon, 23 Jun 2008 00:05:35 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5N7587h002643; Mon, 23 Jun 2008 10:05:29 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 10:05:24 +0300
Received: from net-83.nrpn.net ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 10:05:23 +0300
Message-Id: <D100C512-506D-4979-A008-CA9B3ABAB3E0@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
To: ext Ran Canetti <canetti@csail.mit.edu>
In-Reply-To: <Pine.LNX.4.64.0806161509520.26802@penguin.csail.mit.edu>
Mime-Version: 1.0 (Apple Message framework v924)
Date: Mon, 23 Jun 2008 09:05:18 +0200
References: <Pine.LNX.4.64.0805040027090.18004@penguin.csail.mit.edu> <Pine.LNX.4.64.0806161509520.26802@penguin.csail.mit.edu>
X-Mailer: Apple Mail (2.924)
X-OriginalArrivalTime: 23 Jun 2008 07:05:24.0461 (UTC) FILETIME=[821AE9D0:01C8D4FF]
X-Nokia-AV: Clean
Cc: canetti@watson.ibm.com, secdir@mit.edu, rserpool@ietf.org, Samuel Weiler <weiler+secdir@watson.org>
Subject: Re: [Rserpool] security review of enrp, asap, et al
X-BeenThere: rserpool@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Reliable Server Pooling <rserpool.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rserpool>, <mailto:rserpool-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rserpool>
List-Post: <mailto:rserpool@ietf.org>
List-Help: <mailto:rserpool-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rserpool>, <mailto:rserpool-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: rserpool-bounces@ietf.org
Errors-To: rserpool-bounces@ietf.org
Hi, Ran, since Magnus is on vacation, let me follow up by asking whether you think the remaining issue is a critical one for an Experimental protocol suite, or whether you think that describing it as something the experimenters need to be aware of would be sufficient? Thanks, Lars On 2008-6-16, at 21:26, ext Ran Canetti wrote: > > > I have been asked to review the revised versions of these documents > (from May 29). Of the concerns I raised in the original review blow, > the second one was addressed, by requiring authenticated > communication. The first concern (potential abuse of the system by a > legitimate-but-savvy user or server) does not seem to have been > addressed. Note that this concern does not seem to be solvable using > standard authentication mechanisms (Such as TLS etc), since the > problem is not an authentication problem. One solution is proposed > in my note below. I'm sure other solutions exist as well. > > Also, regarding security threats 1 and 2: I'm not sure how mutual > authentication helps against a malicious ENRP server or a malicious > PE. > They can be completely authentic, yet malicious/hacked... > > Hope this helps, > Ran > > > > On Sun, 4 May 2008, Ran Canetti wrote: > >> >> >> *I have reviewed these documents as part of the security >> directorate's >> *ongoing effort to review all IETF documents being processed by the >> *IESG. These comments were written primarily for the benefit of the >> *security area directors. Document editors and WG chairs should >> treat >> *these comments just like any other last call comments. >> >> >> I have been asked to review: >> >> draft-ietf-rserpool-asap-19 >> draft-ietf-rserpool-common-param-16 >> draft-ietf-rserpool-enrp-19 >> draft-ietf-rserpool-policies-08 >> >> Overall, the documents seem to be well presented and well organized. >> The main comment I have is that I didnt see enough attention paid >> to potential attacks by legitimate pool users and/or pool members. >> >> One issue is that legitimate users may choose to not follow the >> proposed policies regarding choice ofservers (namely, members in >> the pool). >> If the "choose a member at random" policy is employed, then a pool >> user can always set its "random coices" so that it picks a >> partiuclar pool member. This bypasses the "load asharing" idea >> behind the policy. >> another issue is that a pool member (or server) may report a wrong >> policy to a user. >> >> The threats draft, draft-ietf-rserpool-threats I-D, does not seem >> to address such issues. However, I think these issues fit nicely >> within the scope of this protocol suite (if not here, then where >> else). In addition, there do exist simple ways to mitigate some >> attacks of this sort: >> >> To mitigate the first attack, the protocol may require the pool >> user to "prove" to the pool member that the pool member was chosen >> "randomly", say by demonstrating that the random choice was the >> result of applying some hash function to a public nonce. Different >> methods may be appropriate for other member scheduling policies. >> >> To mitigate the second attack, the protocol might require the pool >> server (or members) to sign the policy sent to the user, in a way >> that will allow the user to later hold the server accountable to >> the policy. >> >> Best, >> Ran >> >> > _______________________________________________ > rserpool mailing list > rserpool@ietf.org > https://www.ietf.org/mailman/listinfo/rserpool _______________________________________________ rserpool mailing list rserpool@ietf.org https://www.ietf.org/mailman/listinfo/rserpool
- Re: [Rserpool] security review of enrp, asap, et … Ran Canetti
- Re: [Rserpool] security review of enrp, asap, et … Ran Canetti
- Re: [Rserpool] security review of enrp, asap, et … Lars Eggert