Re: [IPsec] replacing PSKs: CFRG and PAKE

[Nico Williams <[e-mail]>]

On Tue, Dec 11, 2018 at 07:21:26AM -0500, Michael Richardson wrote:
> Nico Williams <[e-mail]> wrote:
> > On Mon, Dec 10, 2018 at 09:20:54PM -0500, Michael Richardson wrote:
> > > Paul Wouters <[e-mail]> 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
--