On 8/30/19 10:51 AM, Paul Wouters wrote:
On Fri, 30 Aug 2019, Dan Harkins wrote:
Administrators doing site-to-site VPNs are better of using a true
random
strong PSK instead of a weaker PAKE.
Well how many administrators generate a nice string of 256-bits of
"true
random strong PSK"? Seriously, if administrators followed such advice
then
we would not continually adding another "die" on the "die die die IKEv1"
routine we seem to do every 9 months. How many "dies" are we up to now?
I did not add killing PSKs to that draft, precisely because some
objected because strong PSK's are stronger than PAKEs.
Strong PSKs are not stronger than PAKEs. A PAKE will offer you the added
protection of resistance to dictionary attack against the symmetric
credential
(which could, in fact, be a PSK).
The definition of dictionary attack is one in which the adversary
gains an
advantage through computation and not interaction. So even with a strong PSK
you are still susceptible to a dictionary attack since it is the
protocol that
is susceptible to attack and not the credential. With a strong PSK it just
makes the dictionary attack use much more time to be successful (and yes the
"true random strong PSK" that's 256 bits could make the attack
computationally
infeasible but then managing such a credential is similarly infeasible).
Think of it this way, if your strong PSK has 64 bits of good randomness
it will take around 2^32 offline computations after A SINGLE ACTIVE
ATTACK to
get a probability of 0.5 of success while if you used that same thing with a
PAKE it would take around 2^32 ACTIVE ATTACKS to get a probability of 0.5.
What a PAKE allows you to do is retain security even in the presence of a
not-so strong PSK. It does not mean the PAKE is weak. We should not be
standardizing a weak PAKE and I don't think any of the candidates that CFRG
is considering are weak.
If you can manage a "strong PSK" then using it with a PAKE makes it
stronger.
If you can't manage a "strong PSK" then a PAKE still increases security.
There's
really no reason to use a PSK exchange susceptible to dictionary attack when
something like SPEKE is available.
regards,
Dan.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
