Yaron Sheffer writes:
> 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?
As far as I can think all of those would be outside the charter.
> And so on and so forth. This would all be highly important if we're
> 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.
> 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.
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/
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
