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.
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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
