On Thu, 24 Jan 2019 at 20:03, Evgeny <[email protected]> wrote: > On Thu, Jan 24, 2019 at 9:15 PM, Dave Cridland <[email protected]> > wrote: > > XMPP-Grid (that draft) essentially says both servers and clients MUST > > implement EXTERNAL, SCRAM-SHA1, SCRAM-SHA1-PLUS, SCRAM-SHA-256, and > > SCRAM-SHA-256-PLUS. > > > > Is there any interest in updating our MTI? > > How can we require SHA-256 when we don't have any way to upgrade > existing deployments from SHA-1? Leaving the burden to the operators > again, because this is out of scope of XSF? :) > Some already suggested "solving" this by forcing password > renewal, but we don't have any mechanisms to do this in XMPP. > > I'm hearing "no", here - which is fine - but I do have a design for enforced password changes and password resets, too. The former is built around SASL2 (XEP-0388) and was actually one of the original design goals. Password resets we built at Surevine as a SASL mechanism (which we used with SASL2, but it'd work with the existing SASL profile in RFC 6120 as well).
I'm going to assume you'd like me to document these? An issue here is that it's impossible under both RFC 6120's SASL profile and XEP-0388 to have a mechanism that'll only work for some users - that is, you can't list SCRAM-SHA-256* only for users who have credentials stored. This has been a matter of deliberate design fairly consistently - otherwise it's possible to test if a user exists or not, which is generally considered bad practise. I personally prefer: > 1) MUST for EXTERNAL and PLAIN > 2) SHOULD for SCRAM-SHA-X-Y (I'd prefer not to use SCRAM at all > given all the problems I have described in another thread) I'm hearing "yes" here, however. Would you be interested in updating the MTI? Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
