On Tue, 11 Dec 2018, Nico Williams wrote:
- you're not entirely sure that you don't have weak PSKs and would like
to strengthen them
I think that this is the major reason.
OK, but you can always convert the real weak PSKs to either PK-{I,raw}
or EAP depending on whether the "client" is a user or not and/or its
capabilities.
I hate the idea of turning weak PSKs, possibly already logged by nation
states, and turn these into PAKEs. I would really hope people do NOT do
that or part of the point of obsoleting PSK's for PAKEs is lost.
I'e, this reason doesn't seem pressing, unless what's pressing is that
somehow a non-EAP PAKE would be much less work for some implementors or
operators (or users) than EAP (w/ EAP-PWD or equivalent).
Yes. Please no EAP where possible.
The moment someone says "and let's add OTP" I think EAP is definitely
the better answer if it already ticks all the capability boxes.
That I can agree too. In general, the OTP use case is a really a
deployment with a human driver in the seat, and not site-to-site or
mesh-node encryption. It's almost always remote access vpn within the
same organisation.
(I wouldn't object, but if EAP fits the bill as to PAKE already, then
thw WG could object to spending its resources on adding PAKE to
IKEv2.)
As explained before. site to site has no way of doing EAP in practise.
I tend to agree. The only case where that's not true is when you have a
site that doesn't already have RADIUS/DIAMETER/WHATEVER AAA
infrastructure and would rather not deploy one. Not sure the WG should
cater to such users.
That is a common case, imagine your 4 home users connecting back to your
simple home vpn gateway.
A site-to-site PAKE is more useful if it isolated from any AAA
infrastructure.
Sure, but does this WG want to cater to that?
Yes we do! One of the goals was to get PSK phased out. So to me this is
the primary use case.
I think a reasonable compromise would be to add a PAKE (both options,
balanced and augmented) but no second factor support.
I have been convinced this is likely the right way forward.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
