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

Yaron Sheffer <yaronf.ietf@gmail.com> Sat, 27 March 2010 14:30 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 CB4D63A6926 for <ipsec@core3.amsl.com>; Sat, 27 Mar 2010 07:30:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.417
X-Spam-Level:
X-Spam-Status: No, score=-0.417 tagged_above=-999 required=5 tests=[AWL=0.433, 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 4I7H7TiiTqge for <ipsec@core3.amsl.com>; Sat, 27 Mar 2010 07:30:28 -0700 (PDT)
Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id CA7993A67FD for <ipsec@ietf.org>; Sat, 27 Mar 2010 07:30:18 -0700 (PDT)
Received: by fxm5 with SMTP id 5so2675535fxm.29 for <ipsec@ietf.org>; Sat, 27 Mar 2010 07:30:43 -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=/HflRntruucE6GKL/GZVDYYsReZH5jnK2gQmR8XjMvo=; b=O+ZYJyZ6f3nxkwuaXE4/6aQWxRHtMq1NVfxlbZA0Y/Vmzxjn1BmzinmE1L+VUOa7TR 4z9v3WCbIp+E7/pg5gN2Xp3J9uOYt5ZdpIs/6cu+UUXTZrvh26LHzwQhhCKjRhY7SZW9 ym8Cgrs9KgHAXPEUe23c92RP5C5g4McU2yCP4=
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=MDCbmRcqbph5Ig5d5OGinhvUssQv8VljQHkoQx2K3OmjFGP+eefmuK7DuMRJOwmblr F+hznneje6wWDSln9KYDHgaQSkE52PVz8gayZ9tNnJ//LkmMj94lSSbyRezIxOM6KwZs VpED/VB23ePuE4du4Kqq5+RbqYRFYVlZ+ww40=
Received: by 10.87.45.33 with SMTP id x33mr6233084fgj.68.1269700242126; Sat, 27 Mar 2010 07:30: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 e20sm1749629fga.21.2010.03.27.07.30.39 (version=SSLv3 cipher=RC4-MD5); Sat, 27 Mar 2010 07:30:41 -0700 (PDT)
Message-ID: <4BAE16A4.60108@gmail.com>
Date: Sat, 27 Mar 2010 17:31: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>
In-Reply-To: <b8b1d491f6e94e8dcc29d4bd15165b32.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 14:30:29 -0000

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