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

Raj Singh <rsjenwar@gmail.com> Tue, 30 March 2010 12:43 UTC

Return-Path: <rsjenwar@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 329F83A68A9 for <ipsec@core3.amsl.com>; Tue, 30 Mar 2010 05:43:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.724
X-Spam-Level:
X-Spam-Status: No, score=-0.724 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 VO0onBs8c3vc for <ipsec@core3.amsl.com>; Tue, 30 Mar 2010 05:43:48 -0700 (PDT)
Received: from mail-yx0-f184.google.com (mail-yx0-f184.google.com [209.85.210.184]) by core3.amsl.com (Postfix) with ESMTP id 5F7A13A6A3E for <ipsec@ietf.org>; Tue, 30 Mar 2010 05:43:41 -0700 (PDT)
Received: by yxe14 with SMTP id 14so1434267yxe.5 for <ipsec@ietf.org>; Tue, 30 Mar 2010 05:44:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=9myxBUKQ8Qu5A2P/uadyv3wigvJbvitZgJZGTvbgy20=; b=YVZuIvN4xFVR+kDGW+8fndQMjlNlVJp5/S+rF9ILXM0gB9BEDtbv/bPOmFg8DqGtQQ B9aVkIFQEFkthRIvIp0VxGctcNigL9UzUDjUP/U8l7iqsSTgQ4i4MT0j17EtSrucEvWM jju0emrqbnAV8MLuKvFb6vdh0d9JwyD099Uv4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ducX2L/16ZB3jOmRDc8VtNEUFaoWGbRFcqifY9qUZiFthdepn0cLSGGjne7dj6wvWn MLAZXvHXVjrm7L1lWbkP/Hd8iQ/MKt6E5DWcw5/xNZeR+NUz1HXe5k18b7b0oZ/mxCI+ ifOGXH8ZUNkNNclkcu+nRBMxa5lsOHC+14sls=
MIME-Version: 1.0
Received: by 10.90.73.11 with HTTP; Tue, 30 Mar 2010 05:43:56 -0700 (PDT)
In-Reply-To: <4BB1EB7A.6000403@gmail.com>
References: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> <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> <4BB1EB7A.6000403@gmail.com>
Date: Tue, 30 Mar 2010 18:13:56 +0530
Received: by 10.90.59.25 with SMTP id h25mr3832708aga.108.1269953038568; Tue, 30 Mar 2010 05:43:58 -0700 (PDT)
Message-ID: <7ccecf671003300543p7e9678d6n1b638eb25165dade@mail.gmail.com>
From: Raj Singh <rsjenwar@gmail.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Content-Type: multipart/alternative; boundary=0016363107dfc0287f048303fb62
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:43:49 -0000

Hi Yaron,

You are saying the same things what i am saying, then i am not able to
understand how its counter example?
The point i want to make here,
"We can emphasize the main use case scenario the draft, but protocol should
have a space for generality".
According to me RFC - 5685 is good example of the above.

Best regards,
Raj


On Tue, Mar 30, 2010 at 5:45 PM, Yaron Sheffer <yaronf.ietf@gmail.com>wrote;wrote:

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