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

Yaron Sheffer <yaronf.ietf@gmail.com> Sat, 27 March 2010 21:20 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 D761A3A6802 for <ipsec@core3.amsl.com>; Sat, 27 Mar 2010 14:20:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.59
X-Spam-Level:
X-Spam-Status: No, score=-0.59 tagged_above=-999 required=5 tests=[AWL=0.260, 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 j1HHhslMMHlM for <ipsec@core3.amsl.com>; Sat, 27 Mar 2010 14:20:22 -0700 (PDT)
Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id E6D9D3A67E3 for <ipsec@ietf.org>; Sat, 27 Mar 2010 14:20:20 -0700 (PDT)
Received: by fg-out-1718.google.com with SMTP id l26so438437fgb.13 for <ipsec@ietf.org>; Sat, 27 Mar 2010 14:20:42 -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=493tTVL1F05Z65d0nF6X04irEClpFodKq96SOh5rmgk=; b=bj2zfpyi5TScwx/PPROucB/ikkr6ji/kcF9fmKu3VdwDKx9EEemIQvHY0L7PiZkQvF J6tUxdd0Q06wYInv/nh3UNw+pxf53yvCGUUCQHy4T2+cMe3RgKPPjAP/v3+1P9pUs8IJ s8tgIFf+8CiNDYca0WBKuU8wK//s5IDNBIl10=
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=HN5EUhb9kKhAcNcYii+6IwQHqLxlgvTUVpVgNSpS4EL4IT8DBQZzlXUmvETkWb1uqh nHaM32ubnAV5lDqbB1BTRSy9qxCdQ1XcFV4ogX3ucle+V9bkYVSlNa9RVSwyHffWrTck j/BH9r7ZQjQsadDL4sp9PMNlw5vkw+K8f8oDQ=
Received: by 10.87.55.11 with SMTP id h11mr1942406fgk.56.1269724842742; Sat, 27 Mar 2010 14:20:42 -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 l12sm3070878fgb.17.2010.03.27.14.20.40 (version=SSLv3 cipher=RC4-MD5); Sat, 27 Mar 2010 14:20:42 -0700 (PDT)
Message-ID: <4BAE76BC.9060508@gmail.com>
Date: Sun, 28 Mar 2010 00:21:00 +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: Dan Harkins <dharkins@lounge.org>
References: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> <4BAC4283.9010002@gmail.com> <018001cacd04$d59efc50$80dcf4f0$@aist.go.jp> <b8b1d491f6e94e8dcc29d4bd15165b32.squirrel@www.trepanning.net> <4BAE16A4.60108@gmail.com> <ae9ff68b6bd2cc3cb59d1cdb433d26a2.squirrel@www.trepanning.net>
In-Reply-To: <ae9ff68b6bd2cc3cb59d1cdb433d26a2.squirrel@www.trepanning.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: ipsec@ietf.org, Kaz Kobara <kobara_conf@m.aist.go.jp>
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: Sat, 27 Mar 2010 21:20:25 -0000

Hi Dan,

Again, the criteria document is just following the charter in mentioning 
this constraint.

The protocol we end up with might have all sorts of nice-to-have 
features and behaviors. But for the criteria, we have to focus on what's 
important. Use cases that were excluded in the charter (and for good 
reason, because we have a perfectly good solution for them today) do not 
fall into this category.

Thanks,
	Yaron

On 27.3.2010 22:15, Dan Harkins wrote:
>
>    Hi Yaron,
>
>    You say below, "If a protocol can be specified for the general use case,
> that's very well. But there will be protocols that are only applicable
> to some specific use cases, and that's fine, too." But then the criteria
> document says, "This document is limited to the use of password-based
> authentication to achieve trust between gateways."
>
>    So basically the criteria document is specifying it for a particular
> use only when there is no protocol issue that would prevent it from being
> used in the general case. It should be "very well" if it worked "for the
> general use case" but the criteria draft is preventing it from doing so.
>
>    In RFC 2409 it was not possible to do the "remote access" thing with a
> PSK because protocol limitations forced the PSK to be bound to one IP
> address. That's an example of a protocol limiting usage. But I don't see
> that now. What could possibly limit what we're talking about _right now_
> to some narrow uses? Maybe when we get around to designing the protocol
> we'll run into something, and as you say "that's fine". But now, there is
> nothing to limit us and no reason to, a priori, say something is for
> "gateways" only.
>
>    Of course, I could be wrong. So maybe you could explain why there is
> some protocol issue that prevents using password-based authentication in
> the general case.
>
>    Dan.
>
> On Sat, March 27, 2010 7:31 am, Yaron Sheffer wrote:
>> Hi Dan,
>>
>> I'm afraid I disagree with you on several counts. See below.
>>
>> Thanks,
>> 	Yaron
>>
>> On 26.3.2010 20:11, Dan Harkins wrote:
>>>
>>>     Telling administrators what they can and cannot do is really not
>>> the function of our standards body. If someone wants to use a
>>> "long secret" or a password to authenticate gateways, hosts, clients,
>>> peers, or implementations (or whatever you want to call the box) it's
>>> none of our business. We shouldn't say, "nope, sorry you can't do that,
>>> this is a client and you should use a stand-alone AAA server because of
>>> the obvious benefits that have eluded you."
>>
>> We cannot tell administrators anything for the simple reason that
>> they're not looking to us for guidance. However we do have some
>> influence over vendors, and we should tell vendors what we think makes
>> sense, i.e. what is the architecturally correct way to use the protocol.
>>
>> More importantly, we should optimize the protocol (only) for the cases
>> that we think are reasonable. So we should care very much about usage
>> scenarios. As a concrete example, password management arguably matters
>> much more to remote access than to gateway-to-gateway scenarios. Should
>> we support it? Depends on the scenario(s) we want to work on.
>>>
>>>     We have RFCs on "host requirements" and "router requirements". There
>>> isn't an RFC on "peer requirements" or "client requirements". Those are
>>> terms that started in marketecture powerpoint slides and should not be
>>> used to constrain or neuter our protocols.
>> No. For years we've had specific IPsec work items on remote access, it's
>> nothing new. If a protocol can be specified for the general use case,
>> that's very well. But there will be protocols that are only applicable
>> to some specific use cases, and that's fine, too.
>>>
>>>     Dan.
>>>
>>> On Fri, March 26, 2010 9:53 am, Kaz Kobara wrote:
>>>> Hi Yaron
>>>>
>>>> Thank you for your clarification.
>>>>
>>>>> "between gateways" as opposed to
>>>>> "between clients and gateways". So your assertion is correct.
>>>>
>>>> (Between gateways, administrators can set long secrets, so the
>>>> necessity
>>>> of
>>>> PAKE seems smaller than between clients and gateways where passwords
>>>> are
>>>> recorded in the gateways and users have to type the passwords.)
>>>>
>>>> Anyway, if the scope is limited only on "between gateways" but not
>>>> "between
>>>> clients and gateways," the title
>>>> "Password-Based Authentication in IKEv2: Selection Criteria and
>>>> Comparison"
>>>> seems misleading (since this itself misinforms that this criteria may
>>>> be
>>>> applied to IKEv2 in any cases), and the above should be clearly
>>>> mentioned
>>>> in
>>>> the document.
>>>>
>>>> Kaz
>>>>
>>>>> -----Original Message-----
>>>>> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
>>>>> Sent: Friday, March 26, 2010 2:14 PM
>>>>> To: Kaz Kobara
>>>>> Cc: ipsec@ietf.org
>>>>> Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway)
>>>>>
>>>>> Hi Kaz,
>>>>>
>>>>> I *thought* my intention was clear: "between gateways" as opposed to
>>>>> "between clients and gateways". So your assertion is correct.
>>>>>
>>>>> Thanks,
>>>>> 	Yaron
>>>>>
>>>>> On 26.3.2010 1:40, Kaz Kobara wrote:
>>>>>> Hi Yaron
>>>>>>
>>>>>>> draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4
>>>>>>> "This document is limited to the use of password-based
>>>>>>> authentication
>>>>> to
>>>>>>> achieve trust between gateways"
>>>>>>
>>>>>> I would like to make sure that
>>>>>> "gateway" in this document does not encompass VPN clients and hosts,
>>>> right?
>>>>>>
>>>>>> Kaz
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On
>>>>> Behalf
>>>>> Of
>>>>>>> Yaron Sheffer
>>>>>>> Sent: Friday, March 26, 2010 3:31 AM
>>>>>>> To: SeongHan Shin
>>>>>>> Cc: IPsecme WG; Kazukuni Kobara
>>>>>>> Subject: Re: [IPsec] New PAKE Criteria draft posted
>>>>>>>
>>>>>>> Hi Shin,
>>>>>>>
>>>>>>> Yes. For the typical remote access VPN, EAP is typically more
>>>>>>> useful.
>>>>>>> Note that there is still need for strong password-based mutual
>>>>>>> authentication EAP methods - but their home is the EMU working
>>>>>>> group.
>>>>>>>
>>>>>>> In addition, the IPsecME has another charter item designed to fit
>>>>> such
>>>>>>> EAP methods (such as the future EAP-AugPAKE :-) into IKEv2.
>>>>>>>
>>>>>>> Please see again the group's charter,
>>>>>>> http://tools.ietf.org/wg/ipsecme/charters.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> 	Yaron
>>>>>>>
>>>>>>> On 25.3.2010 20:07, SeongHan Shin wrote:
>>>>>>>> Dear Yaron Sheffer,
>>>>>>>>
>>>>>>>> I have one question about the draft.
>>>>>>>>
>>>>>>>> draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4
>>>>>>>> "This document is limited to the use of password-based
>>>>> authentication
>>>>>>> to
>>>>>>>> achieve trust between gateways"
>>>>>>>>
>>>>>>>> Is this a consensus of this WG?
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Shin
>>>>>>>>
>>>>>>>> On Thu, Mar 25, 2010 at 3:46 PM, Yaron
>>>>>>>> Sheffer<yaronf.ietf@gmail.com
>>>>>>>> <mailto:yaronf.ietf@gmail.com>>    wrote:
>>>>>>>>
>>>>>>>>        Hi,
>>>>>>>>
>>>>>>>>        after the good discussion in Anaheim, and with the help of
>>>> comments
>>>>>>>>        received on and off the list, I have updated the PAKE
>>>>>>>> Criteria
>>>>> draft
>>>>>>>>        and posted it as
>>>>>>>>
>>>>>>> http://www.ietf.org/id/draft-sheffer-ipsecme-pake-criteria-02.txt.
>>>>>>>>
>>>>>>>>        I have added a number of criteria, clarified others, and
>>>>>>>> added
>>>>>>>>        numbering (SEC1-SEC6, IPR1-IPR3 etc.).
>>>>>>>>
>>>>>>>>        Thanks,
>>>>>>>>            Yaron
>>>>>>>>        _______________________________________________
>>>>>>>>        IPsec mailing list
>>>>>>>>        IPsec@ietf.org<mailto:IPsec@ietf.org>
>>>>>>>>        https://www.ietf.org/mailman/listinfo/ipsec
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> ------------------------------------------------------------------
>>>>>>>> SeongHan Shin
>>>>>>>> Research Center for Information Security (RCIS),
>>>>>>>> National Institute of Advanced Industrial Science and Technology
>>>>> (AIST),
>>>>>>>> Room no. 1003, Akihabara Daibiru 10F,
>>>>>>>> 1-18-13, Sotokannda, Chiyoda-ku, Tokyo 101-0021 Japan
>>>>>>>> Tel : +81-3-5298-2722
>>>>>>>> Fax : +81-3-5298-4522
>>>>>>>> E-mail : seonghan.shin@aist.go.jp<mailto:seonghan.shin@aist.go.jp>
>>>>>>>> ------------------------------------------------------------------
>>>>>>> _______________________________________________
>>>>>>> IPsec mailing list
>>>>>>> IPsec@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> IPsec mailing list
>>>>>> IPsec@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>>
>>>> _______________________________________________
>>>> IPsec mailing list
>>>> IPsec@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>>
>>>
>>>
>>> _______________________________________________
>>> IPsec mailing list
>>> IPsec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipsec
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>
>