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

Yaron Sheffer <yaronf.ietf@gmail.com> Sun, 28 March 2010 09:41 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 D475F3A693D for <ipsec@core3.amsl.com>; Sun, 28 Mar 2010 02:41:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.469
X-Spam-Level:
X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13]
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 o3faummqYEZH for <ipsec@core3.amsl.com>; Sun, 28 Mar 2010 02:41:56 -0700 (PDT)
Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id AC6BC3A6953 for <ipsec@ietf.org>; Sun, 28 Mar 2010 02:41:55 -0700 (PDT)
Received: by fg-out-1718.google.com with SMTP id l26so537013fgb.13 for <ipsec@ietf.org>; Sun, 28 Mar 2010 02:42:18 -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=2CaVS2cVY6wqtyrM2ZVg4s6YAi+mYfoQHVYITk2Dv7E=; b=UtVTpqjkG64oY46a4ofQ77kR+XHWToqLzsJKhP2uNqNEa7UU8wIaGFkf90I0bdwzCe UrMsvagSVZERaneh4+jxlwaSOoDFgTzCGuPil3QSJl3b5tFrn+c8mWHfl+gkYJ5kai5z AiEr4MxiuDydvtXbLyj4rXOwxkJvzOVx+2FjU=
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=D7laD6zUsi0DaDixAI8jPTXiAT7Se4nVMMhiliREEc5ZXRJlbQc5WLS9VYVHn3pKpr qZrxlq82rw9N44tZimO/zW+Wb9BelBVPjEYlAZjZacu9Tt90Tu98YQnBbza/b9OT9hcl yeI2PXq7gU+kbBESJ9urDuxa3jUGCapCE8ExA=
Received: by 10.86.22.31 with SMTP id 31mr5850224fgv.24.1269769338587; Sun, 28 Mar 2010 02:42:18 -0700 (PDT)
Received: from [172.24.251.92] ([192.114.87.4]) by mx.google.com with ESMTPS id l12sm3586615fgb.2.2010.03.28.02.42.16 (version=SSLv3 cipher=RC4-MD5); Sun, 28 Mar 2010 02:42:17 -0700 (PDT)
Message-ID: <4BAF23A4.9010301@gmail.com>
Date: Sun, 28 Mar 2010 12:38:44 +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> <4BAE76BC.9060508@gmail.com> <3dd80c2646eeb2ddf00ce35d10a47a9a.squirrel@www.trepanning.net>
In-Reply-To: <3dd80c2646eeb2ddf00ce35d10a47a9a.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: Sun, 28 Mar 2010 09:41:57 -0000

Hi Dan,

I'm not suggesting to constrain the protocol. I'm trying to focus the 
discussion, and focus the criteria. We both know that integrating an 
existing PAKE into IKEv2 is not such a big deal. But we can spend months 
debating password management:

- Do we specify a password policy?
- Is the policy somehow exposed in the protocol?
- Do you need special error handling to support password policy ("Your 
password will be expiring in 3 days")?
- Do you need special protocol building blocks for password policy, e.g. 
to allow password change?
- Do the IKE transport rules (timeouts) need to change to accommodate 
human input?

And so on and so forth. This would all be highly important if we're 
going after the client-gateway case. I am trying to completely avoid 
this mess by focusing on the problem at hand, rather than trying to 
solve *everything*.

The charter defines the problem we want to solve, based on WG consensus 
and IESG input. I suggest that we stick to it rather than continue 
arguing about it.

Thanks,
	Yaron


On 28.3.2010 3:39, Dan Harkins wrote:
>
>    Hi Yaron,
>
>    Since you did not respond to my question, I guess I can infer then that
> there is no protocol issue _right now_ that would prevent some password
> authentication scheme from being used with a "client" and a "gateway".
> That being the case, the criteria document should not constrain any
> possible solution.
>
>    The charter mentions these use cases because you have to justify _why_
> you want to change the charter, what problem are you solving. Those
> use cases were used to illustrate a problem to solve and justify why the
> charter had to be changed. Just because you happen to solve problem A
> with some protocol does not mean that the protocol must be prevented from
> also solving problem B.
>
>    If you want to use EAP then knock yourself out. If you're happy with
> pointless encapsulation and more state machines and code you have to
> implement then please have at it. But don't make a different protocol
> hamstrung just because it might be used instead of EAP.
>
>    There is no TECHNICAL reason to prevent a password authentication scheme
> in IKE(v2) from being used between a "client" and a "gateway". Since we're
> a working group that deals with technical issues we can therefore safely
> dispense with any artificial constraints on our protocols.
>
>    Dan.
>
> On Sat, March 27, 2010 2:21 pm, Yaron Sheffer wrote:
>> 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
>>>>
>>>
>>>
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>
>