@dcz
$ ls -lrt /
insgesamt 28
drwxr-xr-x 1 root root 14 20. Okt 2014 srv
it's btrfs so no lost+found
on my older laptop I have arch down from 2012 but I'm not using it much (only for network repair as it has physical ethernet port a huge battery) as 'tis bit bulky
@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.
@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.
@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 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.
@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)?
@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 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.
@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).
@sam legacy coding. like it was with infra, when cloud and software-defined-crap came, first it was deragatory "legacy", then after certain time became hybrid (in relation to cloud) and/or clasic (in relation to sd).
@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.
@GossiTheDog where I can find your CV?
@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.
@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.
@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
@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 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 ;(
@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 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
Joined Nov 2019
