Re: [IPsec] replacing PSKs: CFRG and PAKE

[Nico Williams <[e-mail]>]

On Mon, Dec 10, 2018 at 08:58:15PM -0500, Paul Wouters wrote:
> On Mon, 10 Dec 2018, Nico Williams wrote:
> >>That is still missing OTP support :(
> >
> >If you have the private keys locked unextractably in a hardware token
> >that requires a PIN to unlock, then you have two factors right there.
> >That's not generic two-factor authentication though, and it certainly
> >isn't OTP.
> 
> Right. So I guess what I'd like PSK-replacement-PAKE to support is using
> OTP, without EAP. But I guess that's not really possible if I understand
> things correctly.

No you very much can get PAKE + OTP.  We'll get into the details of what
is difficult later.

> If we are going to basically obsolete/deprecate RFC 6628 and 6467, it
> would be nice if we did it in such a way that we can still have OTP
> support.

Sure.

> >A balanced PAKE is symmetric as to initiator/responder roles.  An
> >augmented PAKE is not quite.
> 
> In that case, the gain of augmented PAKE seems small. If the server is

No, the gain of an augmented PAKE is very large.

> compromised, they can just pretend the AUTH payload is OK if they _want_

They can do that in both cases, but in the balanced PAKE case the
attacker who has the shared secret can not only impersonate the server
to the user, but vice-versa, and they can MITM the two.

In the augmented case the attacker who has the verifier can impersonate
the server to the user, but NOT the user to the server (not without
first successfully mounting a dictionary attack on the verifier).

> you to connect to them and get all your traffic. And the client needs to
> know the password, and not just the verifier.

The client is always expected to know the password.  The verifier can
always be computed from the password (and salt).

> For the case where a VPN gateway should not have the password
> credentials itself, it would (should?) be using some kind of EAP
> mechanism anyway? So we don't need an augmented PAKE for that?

EAP has its use: federation.

Augmented PAKE is better than augmented in all cases when dealing with a
username and password as a credential.

Balanced PAKE is only useful (IMO) as a transition tool so that you can
start using the PSK secrets you already have as PAKE secrets then change
passwords to switch to secret/verifier augmented PAKE from that point
forward.

> >The asymmetry in roles in augmented PAKEs means that in order to
> >function as an IKE responder (and thus maintain IKE initiator/responder
> >role symmetry), the IKE PAKE extension would have to permit one side to
> >request that the other initiate the augmented PAKE exchange.
> 
> that feels the wrong method for a site-to-site VPN connecting two
> enterprises. One would have a better security after compromise than
> the other side?

It just means that when the SG/whatever wants to initiate an IKE
exchange with the user it needs an extra message: "Hey yo, start
augmented PAKE with me", followed by the rest of an IKE exchange as if
the now-resonder client had initiated.

> So it seems to me one balanced PAKE would be enough, but I'll go reread
> some older messages again.

Please opt for both.  Balanced so you can start using existing PSKs,
augmented so you can better secure the password database on the server
side.

Nico
--