Update of the SASL SCRAM Downgrade protection XEP

[edhelas]

The value delimiters were changed to prevent some possible attack.

in a nutshell the "," delimiter with 0x1e and the "|" delimiter with 0x1f...the scram attribute key changed from "d" to "h" to get a better upgrade path...

The related PR is there: xsf/xeps#1422
And the rendered version is there: https://dyn.eightysoft.de/xeps/xep-0474.html

Thanks again for the awesome work you're doing on the library !

[fabiang]

Interesting attack vector! There are two key steps we need to address first:

1. Ensure we have server software that supports the new parameter so we can validate it with our integration tests.
2. Decide how to phase out the old parameter: should we trigger a warning when it's used and/or implement a strict mode to reject connections?

@edhelas: Could you provide an update here once XMPP servers has added the parameter?

[tmolitor-stud-tu]

I've already updated Prosody's ssdp module 2 days ago: https://hg.prosody.im/prosody-modules/rev/eedeed1bccf7

The fix for ejabberd was committed yesterday, too: processone/xmpp#99

[fabiang]

Thank you for the information! When I begin working on this issue, I'll attempt to build an ejabberd/ecs Docker image using the latest master branch, if no official version is available by that time.

[tmolitor-stud-tu]

you can use Holger Weiß' test server at messaging.one, too. He deployed my PR there before merging it :)

[tmolitor-stud-tu]

btw: go-sendxmpp and Monal are now patched to implement the fixed version of ssdp, too.

[edhelas]

It seems that some XMPP servers are already patched and Movim cannot login on them anymore :(
Do not hesitate to ping me if you make some advance, I'll do a .z release with the library bump once its fixed :)

[fabiang]

I'm currently waiting for processone/docker-ejabberd#121 to get merged. Without it I can't run the test automatically against a patched version of ejabberd.

[fabiang]

It seems that some XMPP servers are already patched ...

@edhelas Do you know which servers and versions?

[poVoq]

Conversations.im seems to have updated to a development build to fix this specific issue, but it is also coming with the next ejabberd release in a few weeks I guess.

[tmolitor-stud-tu]

It seems that some XMPP servers are already patched and Movim cannot login on them anymore :( Do not hesitate to ping me if you make some advance, I'll do a .z release with the library bump once its fixed :)

@edhelas why should a patched server prevent Movim logins?
Does Movim require the server to support (the old version of) SSDP? That would be bad since many servers do not yet support SSDP at all.
Does Movim have problems with SCRAM attributes it doesn't know? That would be even worse, since the RFC states, that optional SCRAM attributes unknown to the client (or server) MUST be ignored and SHOULD NOT trigger any authentication failures.

[edhelas]

@tmolitor-stud-tu

>>> XMPP sent   
<authenticate xmlns="urn:xmpp:sasl:2" mechanism="SCRAM-SHA-1">
    <initial-response>biwsbj1lZGhlbGFzLHI9b...WEzY2VLUnRRYlovY0w4bW5jMVJRND0=</initial-response>
    <user-agent id="4d6f7669-6d2e-494d-8f34-395576302e32">
        <software>Movim.9MO49U</software>
    </user-agent>
    <bind xmlns="urn:xmpp:bind:0">
        <tag>Movim.9MO49U</tag>
        <enable xmlns="urn:xmpp:carbons:2"/>
    </bind>
</authenticate> 

<<< XMPP received   
<challenge xmlns='urn:xmpp:sasl:2'>cj1tOGpkNz...</challenge> 

>>> XMPP sent   
<response xmlns="urn:xmpp:sasl:2"/> <--- Empty reponse string generated from the library

<<< XMPP received   
<failure xmlns='urn:xmpp:sasl:2'>
    <not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
    <text>Response decoding failed</text>
</failure> 

From what I see with conversations.im the SASL library return an empty response while trying to authenticate. So your questions actually apply there. Movim is only passing the result generated by the library.