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

[Yaron Sheffer <[e-mail]>]

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:[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
>>>>
>>>
>>>
>> _______________________________________________
>> IPsec mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>
>