@Monal I have a question, cannot find it in FAQ/mans. Is monal *only* supporting SASL SCRAM-SHA-*-PLUS now? I'm offering SCRAM-SHA-256 but it closes the stream and shows "weak auth" error. a bit odd and there's no setting to turn it off
@ruff it supports SCRAM with SASL2 and PLAIN with SASL1
@ruff (SCRAM with and without channel binding, e.g. with and without -PLUS)
@Monal yup got it so i need to use /authentication:urn:xmpp:sasl:2 in features instead of /mechanisms:urn:ietf:params:xml:ns:xmpp-sasl for it to accept scram.
@ruff exactly. You can check the wiki at https://monal-im.org for best practices and server configuration advice's, too :)
@Monal Ok, added 0388 implementation, not advertising -PLUS, and getting now this:
_incomplete XEP-0388 support, XEP-0440 MUST be implemented and this mandates that servers MUST at least implement tls-server-end-point__
Ok, fair enough, if server sent PLUS, but it didn't
@ruff you'll have to implement xep-0474 to sign your mechanism list for monal to accept it. Otherwise an attacker could trivially strip the *-PLUS mechanisms and XEP-0440 channel bindings list to downgrade you to no channel binding.
@Monal Ok so only way to use SCRAM is to implement 388 and 474, while PLAIN could be used without all the hassles? like really? :)
@Monal but the whole point was to allow monal to use server with dovecot sasl provider. apparently I cannot force Dovecot to add some extra field to the SASL challenge this effort is futile then ;(
@ruff well, gold security almost always involves some hassle.
That said, maybe we could implement pinning if 0474 isn't supported. That won't protect the very first connection and going from something like SCRAM-SHA-512 to SCRAM-SHA-256 or SCRAM-SHA-1 on the server will leave monal not being able to authenticate (the whole point of pinning is to prevent those downgrades), but it would be better than nothing.
What do you think?
@Monal First problem i see is that monal is sending n,, - it does support PLUS, but server advertised it's not, so it should send y,, instead indicating it didn't see PLUS in adv. That would already allow raising a flag to the server which actually advertised PLUS. That wouldn't allow catching downgrade to SHA-1-PLUS but would prevent downgrade to non-cb SCRAM mech.
@Monal server can then extract this attribute and compare it with own signature. heck it can even strip it and replace with own signature - either way being part of ClientSignature and hence ClientProof its tampering will break the auth.
@Monal Second problem is 474 is intervening into SCRAM mech by forcing undeclared server message. THere is compliant way to do that - optional extensions. I.e. we can include client hash as optional SASL extension attribute:
y,,n=me,r=E3F76B57-CBDE-46A3-979A-F9B1660B0685,g=1B86B264-2A11-4DEF-92C7-6ED78DAFBC95,h=0a1b2c3d4e5f
and that would include it into client-first-bare and hence part of AuthMessage and thus ClientSignature. SASL backend will just ignore it's meaning but keep in AuthMessage