Hi Paul, > >> On the other perhaps we should think of moving Secure Password > >> Framework for IKev2 (RFC6467) and ONE of the associated password > >> authentication methods to standard track, > > > > Strongly support. > > We also talked about that before. A truly strong random PSK is much > stronger than a PAKE. Pushing people to use PAKE might in many cases
No objection. PAKE is not a replacement for PSK, but it has its own niche. It is most appropriate for user authentication, when use doesn't have certificate and cannot remember strong PSK. > decrease the security strength as well. So we cannot get rid of PSK, Nobody proposes getting rid of PSK. > so it seems advise to "use PAKE not PSK" will have the same effect No, it is not a general advise. PAKE is only applicable for some scenarios. > as "don't use weak PSKs" which clearly is not working. Which is why > I feel perhaps at loading time of PSKs, my implementation should reject > certain obviously weak PSKs. On systems using PSKs, we don't tend to > have 1000s of these, just a few. We can spend some CPU cycles on these. > > >> and try to get people to implement > > > > We implemented 6467. > > For users to authenticate with a password, I think EAP methods are far > more common. eg EAP-mschapv2, which you can ask the RADEXT group has > its own set of horrible security features (eg if the EAP messages are > not themselves encrypted to the AAA server). That's why the idea is to use strong password authentication, not broken methods. PAKE as a concept provides a defense against passive dictionary attacks, so it is a big step forward compare to most existing methods. It cannot defend against active brute force attacks though... > >> them. If I remember right CFRG has now selected one augmented and one > >> non-augmented PAKE, so perhaps we could simply say use them, but I have > >> not checked whether we have either one of them defined for Secure > >> Password Framwork (RFC6567) uses. > > > > These methods are CPace (balanced) and OPAQUE (augmented). > > None are defined for 6467 yet. Moreover, both are not > > yet published as RFC. > > We can work on adding these, but I feel that IKE implementations kind of > need to force that a minimum length PSK cannot be used without a PAKE. > Otherwise we just add another unused feature without solving anything. I still think that PAKE is different in its use cases, than PSK. PAKE is good when the secret is not stored on the host at all, only user knows it (so, if your notebook is stolen, the theft gets nothing). PSK assumes that they are stored somewhere, so that no human intervention is needed to access them. Regards, Valery. > Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
