@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? :)
@ruff regarding PLAIN, well, that's the common denominator supported almost everywhere. But it doesn't give any security guarantees at all.
@Monal ok so the idea behind such scrutinity for SCRAM is to avoid user having false perception of being secure by using more secure mech? But if client choses plain - he's on his own and accepts all the risks.
@ruff did you read xep 0474? It contains a whole block of text going into detail why sending "y" isn't as simple as it may seem.
Anyways, we can discuss this further on xmpp, if you want: xmpp:thilo.molitor@juforum.de
@Monal yes, I was part of similar discussion some time ago on xmpp maillist but while i supported the idea it's better to send n when you don't have mechanism to agree on binding type and you suspect that type you support is unlikely to be supported by tge server it's better to send n, but if server is not sending any -PLUS - y for me is a must have. Perhaps I need to undust my xmpp maillist and start it over there.
@ruff it took me several hours to figure out every possible combination of PLUS method (non)advertising, SSDP (non)support and gss header, each with and without mitm attacker. But now I found a way to support your usecase without introducing any new security holes.
Here it is: https://github.com/monal-im/Monal/commit/e19cba5d2917c1cac1a75617fd6bdada15ebcf8f
This will be part of the next beta and stable releases and is already part of the latest alpha release :)
@Monal yup that is exactly what I meant, thanks for improving. I'm still working with my test cases to check ssdp by using sasl optional extensions. first indication is positive though, so once finished with draft implementation will send proposal to the list.
@ruff what proposal exactly do you mean? Ssdp already uses an optional attribute (h is optional, only m would be mandatory).
@Monal this attribute must be sent by server, you cannot force arbitrary sasl backend to send custom attribute. You can send it from the client though as optional extension and any compliant backend should ignore it but include into authmessage (hence signature).
@ruff why should servers not be allowed to send optional attributes? Nothing in the rfc says "optional attributes are only allowed if the client sends them". So: sure, the server is allowed to send optional attributes. And clients are of course allowed to abort authentication if the are not satisfied with the optional attributes they get from the server.
I really don't see the rfc saying otherwise.
@Monal it's not about being "allowed" it's about having possibility. As mentioned early I'm working with dovecot backend. I have no means to inject custom attribute into its server-first. Similar is with other sasl libs i worked with.
@ruff yeah, so you won't be able to implement ssdp, but you would not be able to implement it if the client sent the hash, too.
You need the other side to check the hash. So in principle both directions are possible. But the client needs to know, if the server checks the ssdp hash and that can only be communicated in a scram attribute as well, because it could be manipulated by an attacker otherwise.
@ruff
--> the server always needs to send an optional attribute, either the hash itself, or a flag indicating ssdp support.
@Monal I think you don't understand what I'm saying. SASL SCRAM is not xmpp feature. It is industry standard protocol. It is used with variety of protocols like SMTP, IMAP, LDAP to name a few. And you now want to mandate all libs to support xmpp XEP? like really?
@ruff i want *xmpp servers* to support it, not all sasl libs out there. If you don't support it that's just fine, you just won't get the additional security ssdp provides 🤷♂️
Given that the "industry standard" sasl libs used in smtp/imap don't even support channel-binding to begin with, that's a long way to more secure communication, even without ssdp.
That said, some day the xep might become an rfc.
@Monal my problem right now is i can't make monal working with sasl scram provided via dovecot backend.
Your recent changes should be able to unlock it (if i don't send plus ssdp is not mandatory hence I can still use scram). So I guess for now it should solve my immediate problem. If i want to use PLUS - I will need to use local credentials hence local SCRAM implementation where i can inject h= attribute. So this is also ok.
Only hypothetical future case where dovecot would support cb is a nogo
@Monal I can submit an MR/PR tru dat, but on my experience i can hardly imagine someone actually being openminded enough to accept such a merge. I can try to justify cb-data atrrubute being introduced but sending optional attributes... well will see. Anyway, thanks for a good discussion and your new fixes.
@ruff you could just implement a generic api for adding and reading optional scram attributes. That might be generic enough to be accepted upstream. If they are curious why that might be beneficial, you could point to xep-0474. Maybe we are lucky and it gets accepted :)
But as first contribution, I'd implement an api for cb usage.
@ruff ah, small correction: ssdp isn't mandatory in monal, even when negotiating PLUS, its just mandatory if PLUS can't be negotiated (despite offered by the server) because the 0440 cb list doesn't contain anything supported by monal. Ssdp is needed to proof this fact (otherwise an attacker could just fill the 0440 list with garbage names). If ssdp isn't supported, then the 0440 fallback of tls-server-end-point is assumed to be removed from the 440 list and authentication gets aborted.
@ruff you can always add ssdp support to dovecot should it become necessary for your usecase :)