@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.

@ruff so if you want other sasl libs to support ssdp, you'll have to implement it in this lib. That's exactly the same if you want it to support scram-sha-512: you'll have to implement it in that lib.

@ruff if the client sent the ssdp hash and the server didn't check it, it must be able to employ some other protection mechanisms, like pinning the cb types and sasl methods used. If not, an attacker could still manipulate the cb list or sasl mechanism list without anyone noticing/preventing this.

Always doing the pinning defeats the purpose of ssdp because it prevents full protocol agility (which ssdp tries to restore) and pinning won't secure the first connection either.

@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?

@Monal Do i understand it correctly that current design goal is to make it mandatory to support for server but optional for client? Eg server will always send it but if client is not supporting that it will just transparently pass it over (eg. without actually verifying the signature hash against sdp section)?

@ruff sure, that's mandated by the scram rfc: optional attributes not supported by either server or client MUST be ignored.

@Monal might be the better solution would be to merge ssdp into sasl2 - if client tries to use it server knows client must be sending h=xxx back and if it is missed or modified then it's indication of mitm.
btw recent dovecot backend (v1.3+) claims to support binding, although I don't see backend protocol options which would allow using it - eg a way to send cb-data to be included into c= attribute. So likely will be limited to native connections.

@ruff ssdp can be used with sasl1 (rfc 6120), too. Why limiting it to sasl2? Only the handling of non-support might be different: sasl1 doesn't mandate xep-0440 support, so no lowest common denominator for channel-bindings (tls-server-end-point as lowest common denominator allows a client to abort authentication if PLUS was advertised, but the cb types announced by the server did not include anything the client supported, because at least tls-server-end-point should have been possible)

@Monal Ok then to make it mandatory to implement for sasl2 - i.e. could be used for rfc sasl optionally but for sasl2 mandatory hence client must always send h= when using sasl2. having sasl auth section protected is good regardles of the mech used. Protecting it without server supporting plus could also have merits as a generic downgrade protection.

But yes optional use for rfc with client sending it invalidates the protection as it is sufficient to strip it to emulate client lack of support.

@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

@ruff you can always add ssdp support to dovecot should it become necessary for your usecase :)

@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 ejabberd and prosody both support ssdp, ejabberd out of the box, prosody after activating the community module (and the sasl2 community module). So I don't see any problem here.

Monal has some minimal security requirements (either ssdp or it will employ pinning of mechanisms), but I don't get why that should impose a requirement for any sasl/scram lib out there to support ssdp.