Re: [IPsec] replacing PSKs: CFRG and PAKE

["Valery Smyslov" <[e-mail]>]

Hi Paul,

I think that using PAKE for road warriors is more important than for 
site-to-site VPNs. In the latter case the SGWs are usually administered
by (presumably :-)) experienced administrators, who can select a high-entropy
PSK, and these PSKs need not to be memorable by users. So, generally speaking,
it is more secure to use good PSK than passwords (since any PAKE defends only 
against passive attacks, an attacker can still perform active probes and the search
space is limited for passwords).

So I think that augmented PAKE is more important than balanced. It can be used e.g. 
in those cases when it is impossible to securely store certificate's private key on a 
user devices. I'm not against selecting balanced PAKE too, but I think it's less important.

And I agree that it's better to avoid using EAP for PAKE.

But why do you want to deprecate RFC 6467? It is just a framework that must be
suitable for any PAKE.

Regards,
Valery.


> >> 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.
> 
> With XAUTH, we had a way to transfer a password in an encrypted payload,
> and the password could be in the syntax of "<user_password>:<user_token>"
> 
> 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.
> 
> >> I'd want the PAKE method to support OTP.
> >
> > It's doable.
> 
> Great :)
> 
> >> Explaining these differences on this list would be useful for me and
> >> possibly others.
> 
> Thanks for these.
> 
> > A PAKE is a zero-knowledge password proof protocol (ZKPP) that also
> > provides authenticated key exchange with forward security.  A ZKPP is a
> > password-based authentication protocol where neither eavesdroppers nor
> > active attackers get to mount off-line dictionary attacks on captured
> > protocol material.
> >
> > I had never seen the word "balanced" used to refer to "not augmented",
> > but I like it.
> >
> > A "balanced" PAKE is one where both sides share a secret or secret-
> > equivalent.
> >
> > An "augmented" PAKE is a PAKE where the credentials are asymmetric so
> > that relying parties (servers, acceptors, responders, whatever you call
> > them) store "verifiers" rather than password-equivalent secrets.
> >
> > A verifier is much like a hash of a password: not password-equivalent,
> > but susceptible to off-line dictionary attack.
> >
> > Compromise of shared secrets (via server compromise) is catastrophic for
> > a balanced PAKE since until you're able to change all the secrets the
> > attacker can impersonate all the users to the server.
> >
> > Compromise of verifiers (via server compromise) is much less disastrous
> > for an augmented PAKE because you have some time in which to change all
> > the weak secrets: the time it would take the attacker to recover
> > passwords via off-line dictionary attack.  The verifiers would all be
> > salted, naturally, so if your secrets are reasonably strong then that
> > might be a lot of time to change all those passwords.
> >
> > 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
> compromised, they can just pretend the AUTH payload is OK if they _want_
> you to connect to them and get all your traffic. And the client needs to
> know the password, and not just the verifier.
> 
> 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?
> 
> 
> > 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?
> 
> So it seems to me one balanced PAKE would be enough, but I'll go reread
> some older messages again.
> 
> Paul