Re: [IPsec] New PAKE Criteria draft posted (def. of gateway)

Yaron Sheffer <yaronf.ietf@gmail.com> Tue, 30 March 2010 12:15 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 583E13A6A49 for <ipsec@core3.amsl.com>; Tue, 30 Mar 2010 05:15:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.633
X-Spam-Level:
X-Spam-Status: No, score=-0.633 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_SORBS_WEB=0.619]
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 RvFyc06edXqB for <ipsec@core3.amsl.com>; Tue, 30 Mar 2010 05:15:46 -0700 (PDT)
Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id 664243A6A17 for <ipsec@ietf.org>; Tue, 30 Mar 2010 05:15:10 -0700 (PDT)
Received: by fg-out-1718.google.com with SMTP id d23so3339301fga.13 for <ipsec@ietf.org>; Tue, 30 Mar 2010 05:15:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=YIraCdHJgy3TrNQ/hvrRJoydxegfYFA4/zKA3SJr8Xs=; b=Bj8OjEsacIGZAjiC0I6AXdiG1fDr/5V0EsP1jS1mCRs5TnImWr+aTvb/Zzc8ZTcDUB gHjou+bAzRuDJBwjO8rSUGQfPXX3BVbx21f7naXkEPPSqr4tgDXdDb5GlKMYZsxeRHGE MAgRhBZm6Fs+pXdiBRoc1eFPqcaaObrNNXZ6k=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=sfO0oNoI/ImI46UypddiYt3phCcY7G05Q+gqhxgRCswVhS21UYfC2TQN6Z5/raD2fe 0BTO+v7l6vNkBqA2ys/Ohrs9hfxcLhnzVE0EED/+nnWXB6t6RyGydFcKljKd/BUT2KAJ aZaVVuVMMBMrM8KF4/U1NFaGpnaXDyIFOVbOU=
Received: by 10.86.6.15 with SMTP id 15mr8524315fgf.42.1269951335423; Tue, 30 Mar 2010 05:15:35 -0700 (PDT)
Received: from [10.0.0.1] (bzq-79-183-28-63.red.bezeqint.net [79.183.28.63]) by mx.google.com with ESMTPS id l19sm5572055fgb.26.2010.03.30.05.15.34 (version=SSLv3 cipher=RC4-MD5); Tue, 30 Mar 2010 05:15:35 -0700 (PDT)
Message-ID: <4BB1EB7A.6000403@gmail.com>
Date: Tue, 30 Mar 2010 15:15:54 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3
MIME-Version: 1.0
To: Raj Singh <rsjenwar@gmail.com>
References: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> <018001cacd04$d59efc50$80dcf4f0$@aist.go.jp> <4BAE10BC.7090401@gmail.com> <001001cacdd7$557f0190$007d04b0$@aist.go.jp> <3b12564381bb3d1b9eea9b3276a68487.squirrel@www.trepanning.net> <001801cace41$98e87e10$cab97a30$@aist.go.jp> <4BAF1610.8050004@gmail.com> <000301cace6f$24b23170$6e169450$@aist.go.jp> <4BAF56E7.6040909@gmail.com> <p06240806c7d51823a16f@10.20.30.158> <7ccecf671003290658i4c4c33bbse9b006cd31320854@mail.gmail.com>
In-Reply-To: <7ccecf671003290658i4c4c33bbse9b006cd31320854@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: ipsec <ipsec@ietf.org>, Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Mar 2010 12:15:47 -0000

Hi Raj,

this in fact is the perfect counter-example: RFC 5685 started out with 
the client-gateway scenario, and when we woke up to see how it can be 
generalized to the symmetric gateway-gateway case, it was too late. 
Hence Sec. 10, which says that the resulting protocol is a very partial 
solution for this case.

10.  Use of the Redirect Mechanism between IKEv2 Peers

    The redirect mechanism described in this document is mainly intended
    for use in client-gateway scenarios.  However, the mechanism can also
    be used between any two IKEv2 peers.  But this protocol is
    asymmetric, meaning that only the original responder can redirect the
    original initiator to another server.

I'm not saying that we were right in ignoring this case. I'm saying that 
you can only get the protocol that you want if you define the 
requirements clearly up front.

Thanks,
	Yaron

On 29.3.2010 16:58, Raj Singh wrote:
> Hi Team,
>
> The similar scenarios are beautifully handled by Redirect RFC-5685.
> The Redirect RFC emphasize on client-gateway terminology, which is
> typical use of Redirect mechanism in IKEv2 where Gateway redirects
> client to another less loaded gateway but at the same time RFC is also
> applicable to router-router scenario when one router decides to off-load
> all existing IKEv2 sessions to another gateway when it goes down for
> maintenance etc.
> I totally agree with Paul.
>
> Best regards,
> Raj
>
> On Sun, Mar 28, 2010 at 8:09 PM, Paul Hoffman <paul.hoffman@vpnc.org
> <mailto:paul.hoffman@vpnc.org>> wrote:
>
>     <wg-co-chair-hat on>
>
>     The disagreement between Dan and Yaron is over wording in the
>     not-at-all normative criteria draft. This draft is not intended to
>     become an RFC, and is not binding on the WG. It currently is being
>     edited by Yaron; soon it will be edited by both Yaron and Dan.
>
>      From the active thread the past few days, it seems that Dan
>     disagrees with Yaron's view that people thinking about the PAKE
>     primarily as a gateway-to-gateway solution. That's fine: others in
>     the WG might take one view or the other. I ask that Dan and Yaron
>     produce an -03 with both views in it. I note that the current WG
>     charter does not insist that the PAKE we choose be for
>     gateway-to-gateway, but that it does list "authentication between
>     two servers or routers" as a motivating scenario, and does not list
>     remote access as a motivating scenario for the proposed new work.
>
>     As WG members consider which criteria are important to them, they
>     should also consider what scenarios we want to emphasize in the
>     eventual document. I use the word "emphasize" here because we cannot
>     prevent implementers and administrators from using the new
>     authentication mechanism however they want; we have plenty of
>     experience with IKE and IPsec documents saying "you should use this
>     in that way" that are merrily ignored by large parts of the market.
>
>     --Paul Hoffman, Director
>     --VPN Consortium
>     _______________________________________________
>     IPsec mailing list
>     IPsec@ietf.org <mailto:IPsec@ietf.org>
>     https://www.ietf.org/mailman/listinfo/ipsec
>
>
>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec