Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document adds support for salted password databases to EAP-pwd (RFC5931). I believe the document is Not Ready for the following reasons: 1) The introduction and security considerations fails to acknowledge that password salting is not sufficient to protect against real-world password recovery attacks. Iterative constructs are needed. This knowledge is old, PBKDF2/RFC2898 (which is one standard technique to address the problem) was published in 2000 and has been widely deployed since then. The document should mention this aspect. There have been many successful attacks against pure-salted password databases in the real world, for example: https://en.wikipedia.org/wiki/2012_LinkedIn_hack 2) Code points for the pre-processing techniques PBKDF2 (RFC 2898) and scrypt (RFC 7914) should be added, to support use of best security practices. 3) There are interop concerns with crypt() when discussion about which crypt algorithms (DES, MD5, etc) are to be used is lacking. The page < https://en.wikipedia.org/wiki/Crypt_%28C%29 > mentions a couple of algorithms, but several others exist out there. Consider if the server tells the client to use an exotic crypt() schema like BSDi or NTHASH, and the client does not support this algorithm. The document should discuss the sub-negotiation problem. The document should mention what happens when the server choses an algorithm the client doesn't support. The document should recommend that servers use widely-implemented schemas, like DES, md5, or sha256. 4) Introducing a new pre-processing technique like OpaqueString+SHA1 or OpaqueString+crypt() add complexity. As far as I understand, there are no password databases with OpaqueString-processed passwords which are hashed with SHA-1 or crypt out there today. Thus there is no interop argument for introducing the methods. Please confirm that the intention is to introduce these methods as new ideas. Then let me suggest that you only describe OpaqueString+SHA256 and skip OpaqueString+SHA1, OpaqueString+SHA512, OpaqueString+crypt. This reduces complexity and does not cause a reduction of security. Further, password databases with HTTP Digest MD5 passwords are widely used. For added legacy compatibility, consider support it too. This is not a show stopper, but failure to mentioning it in the context of deployed password databases appears to me like an elephant in the room. Where there conscious reasons for not including it? It may be worth stating those reasons in the document, if that is the case. Cheers, /Simon Attachment: signature.asc Description: PGP signature