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

[Yaron Sheffer <[e-mail]>]

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:[e-mail]]
>>>>> Sent: Friday, March 26, 2010 2:14 PM
>>>>> To: Kaz Kobara
>>>>> Cc: [e-mail]
>>>>> 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: [e-mail] [mailto:[e-mail]] 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<[e-mail]
>>>>>>>> <mailto:[e-mail]>>    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
>>>>>>>>        [e-mail]<mailto:[e-mail]>
>>>>>>>>        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 : [phone]
>>>>>>>> Fax : [phone]
>>>>>>>> E-mail : [e-mail]<mailto:[e-mail]>
>>>>>>>> ------------------------------------------------------------------
>>>>>>> _______________________________________________
>>>>>>> IPsec mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> IPsec mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>>
>>>> _______________________________________________
>>>> IPsec mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>>
>>>
>>>
>>> _______________________________________________
>>> IPsec mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ipsec
>> _______________________________________________
>> IPsec mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>
>