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

From: "Kaz Kobara" <[email-masked]>
Date: Fri, 26 Mar 2010 08:40:51 +0900

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

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 25 Mar 2010 16:59:24 -0700 (PDT)

On the contrary, I would like to see no notion of "clients", "hosts",
and "gateways" at all. There is no reason why this technique could
not be used in any of the use cases in IKEv2.

  And such a statement certainly does not belong in a document that
supposedly deals with criteria upon which a selection will be made.

  Dan.

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 26 Mar 2010 08:06:36 +0300

As I mentioned in my previous mail, the document attempts to follow the 
use cases as agreed in the charter.

For the remote access case, there are clear benefits to having a 
separate AAA server, and EAP has been adopted by multiple protocols 
including IKEv2. I don't see a reason to open this decision now.

And the criteria that this document "supposedly" deals with have to be 
evaluated in the context of use cases and scenarios. They are not 
abstract entities.

Thanks,
	Yaron

On 26.3.2010 1:59, Dan Harkins wrote:
>>>> On Thu, Mar 25, 2010 at 3:46 PM, Yaron Sheffer<[email-masked]
>>>>      [email-masked]<mailto:[email-masked]>
>>>> E-mail : [email-masked]<mailto:[email-masked]>

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 26 Mar 2010 08:13:39 +0300

Hi Kaz,

I *thought* my intention was clear: "between gateways" as opposed to 
"between clients and gateways". So your assertion is correct.

Thanks,
	Yaron

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 26 Mar 2010 08:59:35 -0700 (PDT)

Great, clear benefits to having a separate AAA server. So that's
the reason to neuter technology?

  What you're talking about is a deployment issue and that really isn't
any of our business.

  Dan.

---

From: "Kaz Kobara" <[email-masked]>
Date: Sat, 27 Mar 2010 01:53:17 +0900

Hi Yaron

Thank you for your clarification.

> "between gateways" as opposed to

(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

> From: Yaron Sheffer [mailto:[email-masked]]
> Sent: Friday, March 26, 2010 2:14 PM
> To: Kaz Kobara
> Cc: [email-masked]
> Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway)
> 
> Hi Kaz,
>

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 26 Mar 2010 10:11:59 -0700 (PDT)

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 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.

  Dan.

On Fri, March 26, 2010 9:53 am, Kaz Kobara wrote:
>> >> From: [email-masked] [mailto:[email-masked]] On
>> Behalf
>> Of
>> >> Yaron Sheffer

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 27 Mar 2010 17:05:48 +0300

Hi Kaz,

the deployment experience has been that between gateways, people abuse 
PSK authentication by using it with short passwords. Even though in 
principle they could do better.

Thanks,
	Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 27 Mar 2010 17:31:00 +0300

Hi Dan,

I'm afraid I disagree with you on several counts. See below.

Thanks,
	Yaron

> 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.
> 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.

---

From: "Kaz Kobara" <[email-masked]>
Date: Sun, 28 Mar 2010 03:00:05 +0900

> between gateways, people abuse
> PSK authentication by using it with short passwords.

I agree, but what I wanted to say was
this is also true (and even worse) "between clients and gateways".

> Sent: Saturday, March 27, 2010 11:06 PM
> To: Kaz Kobara
> Cc: [email-masked]
> > applied to IKEv2 in any cases), and the above should be clearly
mentioned
> in

---

From: "Dan Harkins" <[email-masked]>
Date: Sat, 27 Mar 2010 12:15:42 -0700 (PDT)

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:
>>> (Between gateways, administrators can set long secrets, so the
>>> necessity
>>> of
>>>>>>>       received on and off the list, I have updated the PAKE
>>>>>>> Criteria
>>>> draft
>>>>>>>       and posted it as
>>>>>>>

---

From: "Dan Harkins" <[email-masked]>
Date: Sat, 27 Mar 2010 13:46:12 -0700 (PDT)

Kaz,

> this is also true (and even worse) "between clients and gateways".

  So is there a reason you don't want to fix this "between clients
and gateways"?

  Dan.

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 27 Mar 2010 23:53:43 +0300

Actually I do want to fix it. All you have to do is use IKEv2 with one 
of the shining new EAP methods. Such as 
http://tools.ietf.org/html/draft-harkins-emu-eap-pwd-13.

Thanks,
	Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 28 Mar 2010 00:21:00 +0300

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

---

From: "Dan Harkins" <[email-masked]>
Date: Sat, 27 Mar 2010 17:39:30 -0700 (PDT)

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:
>>>>>>> "gateway" in this document does not encompass VPN clients and
>>>>>>> hosts,
>>>>> right?
>>>>>>>
>>>>>>> Kaz
>>>>>>>
>>>>>>>>> E-mail :
>>>>>>>>> [email-masked]<mailto:[email-masked]>

---

From: "Kaz Kobara" <[email-masked]>
Date: Sun, 28 Mar 2010 15:40:46 +0900

>   So is there a reason you don't want to fix this "between clients

(As most of this WG members have already noticed)
PSK in IKE is foolish in the sense that it is vulnerable against off-line
dictionary attack while using heavy DH calculation.

There is no reason not to fix this foolish PSK (regardless of "between
gateways" and "between clients and gateways".)

Kaz

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 28 Mar 2010 11:40:48 +0300

Hi Kaz,

Most of the WG members are aware of the whole picture:

- The standard is clear that PSK must not be used with passwords.
- The standard contains a good solution for the client-gateway case, 
which is already widely implemented, namely EAP. EAP is implemented by 
many AAA servers, is available on endpoints and simple to integrate into 
gateways, and is therefore the best way to set up a remote access 
solution if you have more than, say, 5 users.
- Having two ways to do the same thing (e.g. IKE+EAP with a mutual auth 
method, and IKEv2 with the new proposed mode) is bad for 
interoperability and ultimately, for the success of the standard.

Thanks,
	Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 28 Mar 2010 12:38:44 +0300

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

---

From: "Kaz Kobara" <[email-masked]>
Date: Sun, 28 Mar 2010 21:06:43 +0900

Hi Yaron,

I see. 
Your "client-gateway" means "client-gateway-AAA". 

OK, now we can go back to the title.

Why don't you make it more specific, like
"Password-Based Authentication between Gateways in IKEv2: Selection Criteria
and Comparison" or something like that?

This is really what you want to do, I bet.

Regards,
Kaz

> Sent: Sunday, March 28, 2010 5:41 PM
> To: Kaz Kobara
> Cc: [email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 28 Mar 2010 16:17:27 +0300

Hi Kaz,

Sure. That would be an appropriate title.

Thanks for helping to clarify this point!

Regards,
	Yaron

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 28 Mar 2010 07:39:50 -0700

<wg-co-chair-hat on>

The disagreement between Dan and Yaron is over wording in the not-at-all normative criteria draft. This draft is not intended to become an RFC, and is not binding on the WG. It currently is being edited by Yaron; soon it will be edited by both Yaron and Dan.

>From the active thread the past few days, it seems that Dan disagrees with Yaron's view that people thinking about the PAKE primarily as a gateway-to-gateway solution. That's fine: others in the WG might take one view or the other. I ask that Dan and Yaron produce an -03 with both views in it. I note that the current WG charter does not insist that the PAKE we choose be for gateway-to-gateway, but that it does list "authentication between two servers or routers" as a motivating scenario, and does not list remote access as a motivating scenario for the proposed new work.

As WG members consider which criteria are important to them, they should also consider what scenarios we want to emphasize in the eventual document. I use the word "emphasize" here because we cannot prevent implementers and administrators from using the new authentication mechanism however they want; we have plenty of experience with IKE and IPsec documents saying "you should use this in that way" that are merrily ignored by large parts of the market.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 29 Mar 2010 15:33:14 +0300

> - Do the IKE transport rules (timeouts) need to change to accommodate 

As far as I can think all of those would be outside the charter.

> going after the client-gateway case.

I disagree on that. I do not think those are important for the
protocol point of view regardless whether we have client there or not.

> and IESG input. I suggest that we stick to it rather than continue 

The charter does not rule client-server or client-gateway out, it
mostly just says that we need to define simplier solution than EAP,
but I do not think it only limits you to server-server or
router-router cases.

For example for home or small office solutions there is no AAA server
and using EAP to do remote access would not be feasible, thus I would
expect most of the people currently use plain PSK in those
environments, and they also do use weak passwords, thus would need
something better.

Also I think that kind of scenario is completely within our charter
(if not, point me to the text which rules that out in our charter,
note that it is still within charter even when that specific example
is not given as example in charter).

Most of the scenario text in charter uses words like "such as",
"usually" etc, i.e they are not limiting charter to only those exact
examples.

The goal is defined as:

"The WG will develop a standards-track extension to IKEv2 to allow
mutual authentication based on "weak" (low-entropy) shared secrets.
The goal is to avoid off-line dictionary attacks without requiring the
use of certificates or EAP. "

http://datatracker.ietf.org/wg/ipsecme/charter/
-- 
[email-masked]

---

From: Raj Singh <[email-masked]>
Date: Mon, 29 Mar 2010 19:28:24 +0530

Hi Team,

The similar scenarios are beautifully handled by Redirect RFC-5685.
The Redirect RFC emphasize on client-gateway terminology, which is typical
use of Redirect mechanism in IKEv2 where Gateway redirects client to another
less loaded gateway but at the same time RFC is also applicable to
router-router scenario when one router decides to off-load all existing
IKEv2 sessions to another gateway when it goes down for maintenance etc.
I totally agree with Paul.

Best regards,
Raj

On Sun, Mar 28, 2010 at 8:09 PM, Paul Hoffman <[email-masked]> wrote:

> <wg-co-chair-hat on>
>
> The disagreement between Dan and Yaron is over wording in the not-at-all
> normative criteria draft. This draft is not intended to become an RFC, and
> is not binding on the WG. It currently is being edited by Yaron; soon it
> will be edited by both Yaron and Dan.
>
> From the active thread the past few days, it seems that Dan disagrees with
> Yaron's view that people thinking about the PAKE primarily as a
> gateway-to-gateway solution. That's fine: others in the WG might take one
> view or the other. I ask that Dan and Yaron produce an -03 with both views
> in it. I note that the current WG charter does not insist that the PAKE we
> choose be for gateway-to-gateway, but that it does list "authentication
> between two servers or routers" as a motivating scenario, and does not list
> remote access as a motivating scenario for the proposed new work.
>
> As WG members consider which criteria are important to them, they should
> also consider what scenarios we want to emphasize in the eventual document.
> I use the word "emphasize" here because we cannot prevent implementers and
> administrators from using the new authentication mechanism however they
> want; we have plenty of experience with IKE and IPsec documents saying "you
> should use this in that way" that are merrily ignored by large parts of the
> market.
>
> --Paul Hoffman, Director
> --VPN Consortium

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 30 Mar 2010 15:15:54 +0300

Hi Raj,

this in fact is the perfect counter-example: RFC 5685 started out with 
the client-gateway scenario, and when we woke up to see how it can be 
generalized to the symmetric gateway-gateway case, it was too late. 
Hence Sec. 10, which says that the resulting protocol is a very partial 
solution for this case.

10.  Use of the Redirect Mechanism between IKEv2 Peers

    The redirect mechanism described in this document is mainly intended
    for use in client-gateway scenarios.  However, the mechanism can also
    be used between any two IKEv2 peers.  But this protocol is
    asymmetric, meaning that only the original responder can redirect the
    original initiator to another server.

I'm not saying that we were right in ignoring this case. I'm saying that 
you can only get the protocol that you want if you define the 
requirements clearly up front.

Thanks,
	Yaron

On 29.3.2010 16:58, Raj Singh wrote:
> The Redirect RFC emphasize on client-gateway terminology, which is
> typical use of Redirect mechanism in IKEv2 where Gateway redirects
> client to another less loaded gateway but at the same time RFC is also
> applicable to router-router scenario when one router decides to off-load
> all existing IKEv2 sessions to another gateway when it goes down for
> maintenance etc.
> On Sun, Mar 28, 2010 at 8:09 PM, Paul Hoffman <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     <wg-co-chair-hat on>
>
>     The disagreement between Dan and Yaron is over wording in the
>     not-at-all normative criteria draft. This draft is not intended to
>     become an RFC, and is not binding on the WG. It currently is being
>     edited by Yaron; soon it will be edited by both Yaron and Dan.
>
>      From the active thread the past few days, it seems that Dan
>     disagrees with Yaron's view that people thinking about the PAKE
>     primarily as a gateway-to-gateway solution. That's fine: others in
>     the WG might take one view or the other. I ask that Dan and Yaron
>     produce an -03 with both views in it. I note that the current WG
>     charter does not insist that the PAKE we choose be for
>     gateway-to-gateway, but that it does list "authentication between
>     two servers or routers" as a motivating scenario, and does not list
>     As WG members consider which criteria are important to them, they
>     should also consider what scenarios we want to emphasize in the
>     eventual document. I use the word "emphasize" here because we cannot
>     prevent implementers and administrators from using the new
>     authentication mechanism however they want; we have plenty of
>     experience with IKE and IPsec documents saying "you should use this
>     in that way" that are merrily ignored by large parts of the market.
>
>     --Paul Hoffman, Director
>     --VPN Consortium

---

From: Raj Singh <[email-masked]>
Date: Tue, 30 Mar 2010 18:13:56 +0530

Hi Yaron,

You are saying the same things what i am saying, then i am not able to
understand how its counter example?
The point i want to make here,
"We can emphasize the main use case scenario the draft, but protocol should
have a space for generality".
According to me RFC - 5685 is good example of the above.

Best regards,
Raj

On Tue, Mar 30, 2010 at 5:45 PM, Yaron Sheffer <[email-masked]>wrote:

> Hi Raj,
>
> this in fact is the perfect counter-example: RFC 5685 started out with the
> client-gateway scenario, and when we woke up to see how it can be
> generalized to the symmetric gateway-gateway case, it was too late. Hence
> Sec. 10, which says that the resulting protocol is a very partial solution
> for this case.
>
> you can only get the protocol that you want if you define the requirements
> clearly up front.
>
> Thanks,
>        Yaron
>
>

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 30 Mar 2010 15:51:14 +0300

Hi Raj,

No, RFC 5685 tried for generality without defining the usage scenario in 
advance, and this attempt failed. The solution cannot be used 
gateway-gateway, because it depends on the (arbitrary) 
initiator/responder distinction.

Thanks,
	Yaron

On 30.3.2010 15:43, Raj Singh wrote:
> "We can emphasize the main use case scenario the draft, but protocol
> should have a space for generality".
> On Tue, Mar 30, 2010 at 5:45 PM, Yaron Sheffer <[email-masked]
>     this in fact is the perfect counter-example: RFC 5685 started out
>     with the client-gateway scenario, and when we woke up to see how it
>     can be generalized to the symmetric gateway-gateway case, it was too
>     late. Hence Sec. 10, which says that the resulting protocol is a
>     very partial solution for this case.
>
>     I'm not saying that we were right in ignoring this case. I'm saying
>     that you can only get the protocol that you want if you define the
>         On Sun, Mar 28, 2010 at 8:09 PM, Paul Hoffman
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>         wrote:
>
>         <wg-co-chair-hat on>
>
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>