search

cyrusimap / cyrus-sasl

Other
134 stars 150 forks source link

Add SCRAM-SHA-1-PLUS, SCRAM-SHA-224-PLUS, SCRAM-SHA-256-PLUS, SCRAM-SHA-384-PLUS, SCRAM-SHA-512-PLUS, SCRAM-SHA3-512(-PLUS) supports #552

Open Neustradamus opened 5 years ago

Neustradamus commented 5 years ago

"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]".

SCRAM-SHA-1(-PLUS):

SCRAM-SHA-256(-PLUS):

SCRAM-SHA-512(-PLUS):

SCRAM-SHA3-512(-PLUS):

In more than

It is possible to add?

Linked to:

ksmurchison commented 5 years ago

We can add 224, 384, 512 easily since OpenSSL now appears to support them in the EVP API. -PLUS will take more work. A PR would be appreciated.

Neustradamus commented 5 years ago

Good if you can add a better SHA-2 family (SHA-224, SHA-384, SHA-512) :)

I think, it will be possible to have SHA-3 family (SHA3-224, SHA3-256, SHA3-384, SHA3-512) too?

Who could see for -PLUS variant part?

Have you looked for the documentation?

Neustradamus commented 5 years ago

@ksmurchison: Thanks for SCRAM-SHA-224, SCRAM-SHA-384, SCRAM-SHA-512!

Now there are SCRAM-SHA-1, SCRAM-SHA-224, SCRAM-SHA-256, SCRAM-SHA-384, SCRAM-SHA-512 :)

Have you looked for SCRAM-SHA3?

Neustradamus commented 5 years ago

@dhawes: Please look:

Thanks a lot to @aamelnikov and @ksmurchison too.

Neustradamus commented 4 years ago

@aamelnikov, @ksmurchison: There is a problem, can you look?

SamWhited commented 4 years ago

I'd like to push back on this a bit; adding the PLUS variants of SCRAM-SHA1 and SCRAM-SHA-256 would be great, but the other mechanisms that the OP mentions are not part of the SCRAM family of mechanisms, and are not defined in any IETF standard. That is to say, there is no such mechanism as SCRAM-SHA-512 or SCRAM-SHA-384. Since they are not supported by most SCRAM clients and do not provide any known security benefit over either of the other SCRAM mechanisms (since the hash is just used in an HMAC so only pre-image attacks would matter), please consider removing these mechanisms or at least disabling them by default.

If the mechanisms are left in, and eventually a SCRAM-SHA-512 mechanism is created by the IETF but it differs somehow from the other mechanisms, you will have an incompatible version. This also may encourage other developers to implement the non-standard mechanism and/or to not support the actual standardized mechanisms out of some misguided idea that bigger numbers means that it is somehow "more secure". We don't want to have to clean up a mess later, or encourage other SCRAM stacks to invent their own mechanisms which may only work with one or two clients and servers when safe, standardized, mechanisms have already been thought through by a group with expertise in these matters.

TL;DR let's not make up our own crypto, it's dangerous. Please trust the experts and wait until the IETF reviews and standardizes a new mechanism before implementing it.

Thanks for your consideration.

Neustradamus commented 4 years ago

SCRAM-SHA-512(-PLUS):

SCRAM-SHA3-512(-PLUS):

SamWhited commented 4 years ago

Those are I-Ds, not RFCs. They are IDs by a well respected author, and if they are ever accepted then we should use them. In the mean time let's not make up our own crypto, it's bad practice.

Neustradamus commented 4 years ago

@SamWhited: It will be validated soon :) A good job from @aamelnikov. In several RFCs, there are some links to draft before RFC.

SamWhited commented 4 years ago

I certainly hope so, and when it is then we can use them, as I've said on every other issue where you've pushed people to make up their own auth mechanisms for some reason.

Neustradamus commented 4 years ago

@SamWhited: Do not forget that the code for SCRAM in Cyrus SASL has been done by the author of the SCRAM RFCs himself @aamelnikov and by @ksmurchison too.

Neustradamus commented 4 years ago

A lot of projects have already SCRAM-SHA-512: https://www.google.com/search?q=SCRAM-SHA-512

SamWhited commented 4 years ago

I'm sure the code is fine, and I'm very excited they're writing I-Ds to update the registry, I'm pushing back against implementing them and encouraging others to use non-standardized mechanisms before we're sure what the final version of those mechanisms looks like. Chances are they won't change, and I'll be very excited to see these mechanisms implemented once they are in the registry.

A lot of projects implementing it doesn't mean it's a good idea, and most mainstream services don't implement it, so you're not even getting any sort of compatibility befit from rushing an implementation.

quanah commented 4 years ago

I see no major issue here. Any pull request should be against the master (development) branch, and not against the 2.1 release branch. I would suggest putting the non-finalized RFC versions behind an IFDEF that can be flagged at compile time for people who want to enable/experiment with them. If the finalized form differs, we can fix and unifdef them for them to be officially supported. It is quite common for draft form RFCs to be implemented in software while the draft is finalized (For example, see password policy support found in most all LDAP projects, despite it still being in draft form).

SamWhited commented 4 years ago

I would suggest putting the non-finalized RFC versions behind an IFDEF that can be flagged at compile time for people who want to enable/experiment with them.

Putting them behind an IFDEF seems good enough to me.

Neustradamus commented 2 years ago

It is official, it is here: RFC 9266: Channel Bindings for TLS 1.3:

Thanks @SamWhited.

Neustradamus commented 1 year ago

@aamelnikov, @ksmurchison, @quanah, @hyc, @bgermann: It is possible to add SCRAM-SHA3-512?

Can you see for Channel Binding too?

Thanks in advance.

Neustradamus commented 1 year ago

Dear @cyrusimap team, @aamelnikov, @ksmurchison, @quanah, @hyc, @bgermann, @dilyanpalauzov, @iboukris, @simo5,

Can you look for Channel Binding for TLS 1.3 support?

There is a recent history with jabber.ru MITM and SCRAM-SHA-*-PLUS is the security solution!

Some sources about jabber.ru:

Thanks in advance.

Linked to: