On Tue, Dec 11, 2018 at 07:21:26AM -0500, Michael Richardson wrote:
> Nico Williams <[email protected]> wrote:
> > On Mon, Dec 10, 2018 at 09:20:54PM -0500, Michael Richardson wrote:
> > > Paul Wouters <[email protected]> wrote:
> > > > > yes, typo, "not for road-warrior"
> > > >
> > > > I understood. I disagree with the “not”. Road warriors using
> > > > group psk is a thing, sadly.
> > >
> > > But they aren't cross-domain, they can do EAP-foobar, and they
> > > could use a certificate without a lot of hassle about what set of
> > > trust anchors.
> > >
> > > If we stick to the site-to-site then I think we can do something
> > > rather simple and quick, and our security considerations section
> > > will be much simpler.
> >
> > I mean, if road warriors should always be using either EAP or user
> > certs, then we don't need PAKE for anything because presumably the
> > shared keys used in PSKs are strong enough that PAKEs don't improve
> > security and only slow things down...
>
> It's the enterprise-to-enterprise connection that is hard to convert
> to certificates for the reasons that Paul explained.
Is it not better to think of it as federation? Is it not federation?
> > (I'm assuming you mean to use an EAP method like EAP-PWD (RFCs 5931 and
> > 8146), yes?)
> >
> > Assuming you can always use EAP, the only real reasons to use a PAKE in
> > IKEv2 are:
> >
> > - 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'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).
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.
> > - you don't always want EAP for users who don't have certs for reasons
> > that escape me
> >
> > (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.)
>
> I think that a user-oriented PAKE is more useful if it can be
> backended into a AAA infrastructure, which EAP can.
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.
> 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?
I think a reasonable compromise would be to add a PAKE (both options,
balanced and augmented) but no second factor support.
Nico
--
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec