SASL SCRAM Downgrade Protection, support to inject specific value in optional parameter

[edhelas]

Hi, I'm currently implementing https://xmpp.org/extensions/xep-0474.html

In the flow I actually need to reuse the same mechanism used for the password for a specific string that will then be appended as an optional 'd=' parameter at the end (see https://xmpp.org/extensions/xep-0474.html#hash).

To do so I'd need to have a specific accessor to your library to re-use the mechanism that you're running internally to generate the responses.

Do you have some good ideas of how this could be done ? Or other ways that I could use properly your lib to implement this standard ?

Thanks for the good work !

Regards,

edhelas

Related to movim/movim#1275

[fabiang]

I assume we need to pass the possible values for the mechanism and channel-binding list to Fabiang\Sasl\Authentication\SCRAM::createResponse(). When Fabiang\Sasl\Authentication\SCRAM::generateResponse() is called and d= is provided we simply return false if the SHA1 doesn't match.

In the example the order of mechanisms/channel-binding list is "SCRAM-SHA-1, SCRAM-SHA-1-PLUS, tls-server-end-point, tls-exporter", but in it says: "Attribute "d" contains base64 encoded SHA-1 hash of 'SCRAM-SHA-1,SCRAM-SHA-1-PLUS|tls-exporter,tls-server-end-point'". What is the logic here how to order this list?

[edhelas]

So basically it could be your library that can take care of injecting the proper d= element ? That would be great indeed :)

For the sorting the XEP actually specifiy this

Note: All sorting operations MUST be performed using "i;octet" collation as specified in Section 9.3 of RFC 4790 [9].

[fabiang]

Yes this library should be responsible for validating the d= parameter.

I'm still unsure if we should pass the mechanism and channel-binding list via the Options class or by parameter to createResponse(). And secondly backward compatibility: if no allowed mechanism and channel-binding list is provided, ignore d= completely or return false?

[edhelas]

I think it would be simpler when you actually instanciate it ? You can have a look at my usage of your library there https://github.com/movim/movim/blob/master/src/Moxl/Authentication.php

I am not sure about the second one

[fabiang]

I think it the better solution would be, to initiate the Options class with the expected values and force users of this library to create a new object for each authentication try (exactly how Movim does).

I'm gonna pick this issue up in the following days. @edhelas I assume you can test the changes?

[edhelas]

Yes for sure ! :)

[fabiang]

I've implemented downgrade protection (dp) for SCRAM in branch scram-downgrade-protection. It's still optional, so if you don't setup dp correctly, you're still able to connect. The README.md given more info on how to set it up: https://github.com/fabiang/sasl/tree/scram-downgrade-protection?tab=readme-ov-file#scram-downgrade-protection

[edhelas]

Thanks, I'll have a look at it !

[edhelas]

Seems to work for me :) ! I made a PR with your branch integration in Movim there movim/movim#1303

I also added support for the channel-binding feature even though it is not supported in PHP for now.

Be careful you have a typo at allowed_machanisms.

Tell me if I forgot something in my implementation. I'll amend my PR once you fixed the typo, merged and taggued a new release.

Thanks a lot for the awesome work !

[fabiang]

Created a new release v1.4.0

[Neustradamus]

@fabiang: Thanks a lot for the new release build with your "XEP-0474: SASL SCRAM Downgrade Protection" fix!