-
Notifications
You must be signed in to change notification settings - Fork 428
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SCRAM-SHA-1(-PLUS) + SCRAM-SHA-256(-PLUS) supports #2442
Comments
This is definitely a very good idea. Sadly, we probably won't manage to add them for the next release but I'll add this request to our internal backlog. |
This comment was marked as spam.
This comment was marked as spam.
We haven't forgotten about this but the upcoming release is currently focused on different items. |
@Neustradamus can you explain (or point as to a documentation) how existing accounts using SCRAM-SHA-1 can be migrated to SCRAM-SHA-256. If I understand it correctly there is no other option as setting new password with the new mechanism. |
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
@Neustradamus Happy New Year 2020! The next MongooseIM release is planned for end of January. I'll make sure this issue gets done as one of the first after the release. And thanks for reminding about this! |
This comment was marked as spam.
This comment was marked as spam.
We have some other things planned for the upcoming release and I'm not sure we'll be able to fit this one. Just for the record, MongooseIM already supports |
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
Hi @Neustradamus, this is one of our top priorities for the next release. I did initial research regarding the possibility of adding Also I'm wondering how important is it to allow users to switch between the methods. If I understand it correctly in order to allow both |
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
Hi @Neustradamus, Thanks for the provided suggestions, much appreciated! We are still working on those modules and the naming might still change. It will mostly depend on the functionalities and differences to '_sha256' modules. We'll let you know where do we land at. |
Hi @Neustradamus, Thanks for keeping a close and detailed eye on the Answering to your questions:
|
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
Thanks for the PRs @Neustradamus :) I merged #2719 and the change you proposed in #2720 will be included in a PR which @janciesla8818 is currently working on. Thanks for keeping a close eye on the |
Regarding the following question from @Neustradamus
An admin will be able to configure:
|
This comment was marked as spam.
This comment was marked as spam.
Do you mean the order on the list of supported mechanisms when the server advertises it to the client? |
This comment was marked as spam.
This comment was marked as spam.
@Neustradamus the advertised list of authentication mechanisms can be adjusted. @janciesla8818 what do you think? When it comes to selecting the authentication mechanism by the client, my understanding is that if the client is capable of channel binding and advertises it to the server, it will not be allowed to use other scram mechanisms than Moreover, when the server advertises an authentication mechanism, it will be possible for the client to authenticate with the mechanism unless:
At this point, I don't see much value (on the server side) in adding such test case which iterates over all the mechanisms. |
This comment was marked as spam.
This comment was marked as spam.
Hi @Neustradamus I think the last PR in this topic is this one #2745 |
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
Hi @Neustradamus, after releasing 3.7 we took a break for breathing and focusing on some other matters. When it comes to the test on xmpp.net the result may be dissatisfying for you. MongooseIM currently advertises and allows to authenticate even before STARTTLS sessions. It can be configured to require STARTTLS, in this case, the authentication will be rejected but still advertised on the plain connection. Could you point us to a XEP, describing the best practices regarding TLS and advertised features? |
When it comes to LDAP authentication backend, currently it works only with |
This comment was marked as spam.
This comment was marked as spam.
Hi @Neustradamus, I'm gonna try to keep these topics organised.
With that said, I'd like to close this old issue, I believe it has been solved. Let me know if you're fine with this. |
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
@Neustradamus That issue in Conversations has nothing to do with the protocol, but rather with their internal implementation of the |
This comment was marked as spam.
This comment was marked as spam.
Hi @Neustradamus, I've seen the TLS 1.3 channel binding, it's on my personal task list. But first I need support for that in the underlying TLS libraries, and also, some code cleanup in MIM usage of the TLS libraries. So it'll take a while for this to be done, you don't need to remind me, I won't forget, but it won't be soon I'm afraid. Thanks for the heads up! PS: you probably wanted to tag @michalwski, not @michalslaski ;) |
This comment was marked as spam.
This comment was marked as spam.
No change of username, those are two different Michałs 😛 |
"When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802]".
Can you add support for?
SCRAM-SHA-1(-PLUS):
-- https://tools.ietf.org/html/rfc5802
-- https://tools.ietf.org/html/rfc6120
SCRAM-SHA-256(-PLUS):
-- https://tools.ietf.org/html/rfc7677 since 2015-11-02
-- https://tools.ietf.org/html/rfc8600 since 2019-06-21: https://mailarchive.ietf.org/arch/msg/ietf-announce/suJMmeMhuAOmGn_PJYgX5Vm8lNA
SCRAM-SHA-512(-PLUS):
SCRAM-SHA3-512(-PLUS):
https://xmpp.org/extensions/inbox/hash-recommendations.html
-PLUS variants:
LDAP:
HTTP:
2FA:
IANA:
Note:
RFC6331: Moving DIGEST-MD5 to Historic
Linked to:
The text was updated successfully, but these errors were encountered: