Re: [IPsec] replacing PSKs: CFRG and PAKE

[Nico Williams <[e-mail]>]

On Mon, Dec 10, 2018 at 11:22:46AM +0300, Valery Smyslov wrote:
> > I think we should ask the CFRG to pick a single balanced PAKE for us.
> 
> Why do you think balanced PAKE is more appropriate for us than augmented?

Speaking for myself rather than Michael, I think augmented is more
appropriate when the key is based on a memorable password.

However, but transition reasons, it's desirable to support a
non-augmented PAKE with _existing_ password-derived keys.

Also, even for non-password-derived symmetric keys, a PAKE automatically
adds forward security, so it seems like a nice simplification to use a
non-balanced PAKE in all cases where the credentials are shared secret
keys.

So in fact we probably want both.

> > If the CFRG want to pick another PAKE for other purposes, that's fine.
> > I think that letting CFRG pick two PAKEs for different purposes might
> > free up the log jam?
> 
> They've just announced in Bangkok a desire to start the process of selecting
> "zero or more" recommended PAKE(s) for IETF community.
> I believe IPsec is included :-)

Oh?  I thought the CFRG SPAKE2 I-D was further along.  I'll have to ask
the I-D authors and RG chairs.

In any case, KITTEN WG is moving along with a Kerberos extension to use
the CFRG SPAKE2 protocol -- this is past WGLC and awaiting shepherding
to the IESG now.  If CFRG ultimately picks a different PAKE, or no PAKE,
that could be a problem for the KITTEN work.

> Another problem with PAKE is that it must be integrated into IKE
> somehow.  EAP definitely can be used for this, but it's a bit

Do you mean enrolment and password change protocols?  Enrolment could be
left unspecified, but a password change protocol is required.

> expensive from protocol point of view.  We also have RFC 6467, but

Oh, no, you meant a document like RFC 6467.  Yes, such a document would
be necessary -- I don't think Michael meant to imply otherwise.

> it's Informational and I'm not sure it's widely supported.  And while
> the RFC 6467 framework is flexible enough, it is still not clear for
> me if it can accommodate PAKEs like OPAQUE...

It might be possible to build a single IKE extension that can handle any
number of PAKEs, since they will generally involve a small number of
round trips of exchanges of PAKE-specific octet strings, followed by a
generic key confirmation exchange that involves binding in the PAKE's
transcripts and at least the IKE ID payloads.

There's also the opportunity to add support for second factors (e.g.,
OTPs).  The KITTEN SPAKE work does that, though it's got some issues, so
this WG might not want to copy that approach.

Note that there are all these things to negotiate:

 - PAKE
    - including whether to use a symmetric or augmented variant
 - curve/group
 - second factor

The KITTEN WG SPAKE work did not include PAKE negotiation nor augmented
vs. not-augmented negotiation :(

Nico
--