Re: [VOTE] KIP-84: Support SASL SCRAM mechanisms

[Ismael Juma <is...@juma.me.uk>]

Rajini, I think it's time to declare this vote as successful. :)

Ismael

On Wed, Dec 21, 2016 at 10:57 AM, Rajini Sivaram <ra...@gmail.com>
wrote:

> Jun,
>
> The KIP currently proposes to add 4 SASL mechanisms SCRAM-SHA-224,
> SCRAM-SHA-256, SCRAM-SHA-384 and SCRAM-SHA-512. Ismael suggested supporting
> just SCRAM-SHA-256 and SCRAM-SHA-512 to make it easier for non-Java client
> support. What do you think?
>
> Thank you,
>
> Rajini
>
>
> On Fri, Dec 2, 2016 at 2:44 PM, Ismael Juma <is...@juma.me.uk> wrote:
>
> > Thanks Rajini. Let's see what Jun says about limiting the number of SHA
> > variants. Either way, +1 from me.
> >
> > Ismael
> >
> > On Fri, Dec 2, 2016 at 2:40 PM, Rajini Sivaram <
> > rajinisivaram@googlemail.com
> > > wrote:
> >
> > > Ismael,
> > >
> > > 1. Jun had suggested added the full list of SHA-nnn in the [DISCUSS]
> > > thread. I am ok with limiting to a smaller number if required.
> > >
> > > 3. Added a section on security considerations to the KIP.
> > >
> > > Thank you,
> > >
> > > Rajini
> > >
> > > On Thu, Dec 1, 2016 at 4:22 PM, Ismael Juma <is...@juma.me.uk> wrote:
> > >
> > > > Hi Rajini,
> > > >
> > > > Sorry for the delay. For some reason, both of your replies (for this
> > and
> > > > KIP-85) were marked as spam by Gmail. Comments inline.
> > > >
> > > > On Mon, Nov 28, 2016 at 3:47 PM, Rajini Sivaram <
> > > > rajinisivaram@googlemail.com> wrote:
> > > > >
> > > > > 1. I think you had asked earlier for SCRAM-SHA-1 to be removed
> since
> > it
> > > > is
> > > > > not secure :-) I am happy to add that back in so that clients which
> > > don't
> > > > > have access to a more secure algorithm can use it. But it would be
> a
> > > > shame
> > > > > to prevent users who only need Java clients from using more secure
> > > > > mechanisms. Since SHA-1 is not secure, you need a secure Zookeeper
> > > > > installation (or store your credentials in an alternative secure
> > > store)..
> > > > > By supporting multiple algorithms, we are giving the choice to
> users.
> > > It
> > > > > doesn't add much additional code, just the additional tests (one
> > > > > integration test per mechanism). As more clients support new
> > > mechanisms,
> > > > > users can enable these without any changes to Kafka.
> > > > >
> > > >
> > > > Yes, I remember that I asked for SCRAM-SHA-1 to be removed. I
> probably
> > > > wasn't clear. My suggestion was not to add that back, but whether we
> > > needed
> > > > so many variants. For example, we could support SCRAM-SHA-256 and
> > > > SCRAM-SHA-512.
> > > > Would that be sufficient? It's true that the cost is not that large
> for
> > > us,
> > > > but every other client also has to pay that additional extra cost
> and I
> > > am
> > > > not sure sure about the benefit of some of the options.
> > > >
> > > > 3. I am assuming that ZK authentication will be enabled and ZK
> > > > > configuration will be done directly using ZK commands. This is true
> > for
> > > > > ACLs, quotas etc. as well?
> > > > >
> > > >
> > > > Right, I also thought that ACLs was the closest example. However, it
> > > seems
> > > > like getting read access to the SCRAM DB has potentially worse
> > > > consequences:
> > > >
> > > > "For a specific secret compromised, if an exchange is obtained from
> the
> > > > wire by some mechanism, this gives sufficient information for an
> > imposter
> > > > to pose as the client for that server (but not another one using the
> > same
> > > > password). Note that this interception is only useful if the database
> > has
> > > > been compromised – SCRAM is safe against replay attack. This is the
> > > primary
> > > > SCRAM weakness, and why it is important to protect the secret
> database
> > > > carefully and to use TLS."[1]
> > > >
> > > > Also, because we are using fast hashes (instead of slow ones like
> > bcrypt,
> > > > scrypt, etc.), we are more susceptible to dictionary attacks
> > (potentially
> > > > mitigated by a reasonably large iteration count combined with good
> > > quality
> > > > passwords).
> > > >
> > > > If nothing else, it may be worth mentioning some of this in the KIP
> > > and/or
> > > > documentation.
> > > >
> > > > Ismael
> > > >
> > > > [1] http://www.isode.com/whitepapers/scram.html
> > > >
> > >
> > >
> > >
> > > --
> > > Regards,
> > >
> > > Rajini
> > >
> >
>

Re: [VOTE] KIP-84: Support SASL SCRAM mechanisms

[Rajini Sivaram <ra...@gmail.com>]

Oops, I had sent the following note, but it was sent as a response to Jun
Rao and I didn't realize it wasn't sent to dev list. Thanks for pointing
out, Ismael. The KIP has been moved to adopted list.


*This vote has passed with three binding (Gwen, Jun, Ismael) and three
non-binding votes (Mickael, Edo, me). *

*Thank you all for your votes and feedback.*


On Fri, Jan 6, 2017 at 3:58 PM, Ismael Juma <is...@juma.me.uk> wrote:

> Rajini, I think it's time to declare this vote as successful. :)
>
> Ismael
>
> On Wed, Dec 21, 2016 at 10:57 AM, Rajini Sivaram <ra...@gmail.com>
> wrote:
>
> > Jun,
> >
> > The KIP currently proposes to add 4 SASL mechanisms SCRAM-SHA-224,
> > SCRAM-SHA-256, SCRAM-SHA-384 and SCRAM-SHA-512. Ismael suggested
> supporting
> > just SCRAM-SHA-256 and SCRAM-SHA-512 to make it easier for non-Java
> client
> > support. What do you think?
> >
> > Thank you,
> >
> > Rajini
> >
> >
> > On Fri, Dec 2, 2016 at 2:44 PM, Ismael Juma <is...@juma.me.uk> wrote:
> >
> > > Thanks Rajini. Let's see what Jun says about limiting the number of SHA
> > > variants. Either way, +1 from me.
> > >
> > > Ismael
> > >
> > > On Fri, Dec 2, 2016 at 2:40 PM, Rajini Sivaram <
> > > rajinisivaram@googlemail.com
> > > > wrote:
> > >
> > > > Ismael,
> > > >
> > > > 1. Jun had suggested added the full list of SHA-nnn in the [DISCUSS]
> > > > thread. I am ok with limiting to a smaller number if required.
> > > >
> > > > 3. Added a section on security considerations to the KIP.
> > > >
> > > > Thank you,
> > > >
> > > > Rajini
> > > >
> > > > On Thu, Dec 1, 2016 at 4:22 PM, Ismael Juma <is...@juma.me.uk>
> wrote:
> > > >
> > > > > Hi Rajini,
> > > > >
> > > > > Sorry for the delay. For some reason, both of your replies (for
> this
> > > and
> > > > > KIP-85) were marked as spam by Gmail. Comments inline.
> > > > >
> > > > > On Mon, Nov 28, 2016 at 3:47 PM, Rajini Sivaram <
> > > > > rajinisivaram@googlemail.com> wrote:
> > > > > >
> > > > > > 1. I think you had asked earlier for SCRAM-SHA-1 to be removed
> > since
> > > it
> > > > > is
> > > > > > not secure :-) I am happy to add that back in so that clients
> which
> > > > don't
> > > > > > have access to a more secure algorithm can use it. But it would
> be
> > a
> > > > > shame
> > > > > > to prevent users who only need Java clients from using more
> secure
> > > > > > mechanisms. Since SHA-1 is not secure, you need a secure
> Zookeeper
> > > > > > installation (or store your credentials in an alternative secure
> > > > store)..
> > > > > > By supporting multiple algorithms, we are giving the choice to
> > users.
> > > > It
> > > > > > doesn't add much additional code, just the additional tests (one
> > > > > > integration test per mechanism). As more clients support new
> > > > mechanisms,
> > > > > > users can enable these without any changes to Kafka.
> > > > > >
> > > > >
> > > > > Yes, I remember that I asked for SCRAM-SHA-1 to be removed. I
> > probably
> > > > > wasn't clear. My suggestion was not to add that back, but whether
> we
> > > > needed
> > > > > so many variants. For example, we could support SCRAM-SHA-256 and
> > > > > SCRAM-SHA-512.
> > > > > Would that be sufficient? It's true that the cost is not that large
> > for
> > > > us,
> > > > > but every other client also has to pay that additional extra cost
> > and I
> > > > am
> > > > > not sure sure about the benefit of some of the options.
> > > > >
> > > > > 3. I am assuming that ZK authentication will be enabled and ZK
> > > > > > configuration will be done directly using ZK commands. This is
> true
> > > for
> > > > > > ACLs, quotas etc. as well?
> > > > > >
> > > > >
> > > > > Right, I also thought that ACLs was the closest example. However,
> it
> > > > seems
> > > > > like getting read access to the SCRAM DB has potentially worse
> > > > > consequences:
> > > > >
> > > > > "For a specific secret compromised, if an exchange is obtained from
> > the
> > > > > wire by some mechanism, this gives sufficient information for an
> > > imposter
> > > > > to pose as the client for that server (but not another one using
> the
> > > same
> > > > > password). Note that this interception is only useful if the
> database
> > > has
> > > > > been compromised – SCRAM is safe against replay attack. This is the
> > > > primary
> > > > > SCRAM weakness, and why it is important to protect the secret
> > database
> > > > > carefully and to use TLS."[1]
> > > > >
> > > > > Also, because we are using fast hashes (instead of slow ones like
> > > bcrypt,
> > > > > scrypt, etc.), we are more susceptible to dictionary attacks
> > > (potentially
> > > > > mitigated by a reasonably large iteration count combined with good
> > > > quality
> > > > > passwords).
> > > > >
> > > > > If nothing else, it may be worth mentioning some of this in the KIP
> > > > and/or
> > > > > documentation.
> > > > >
> > > > > Ismael
> > > > >
> > > > > [1] http://www.isode.com/whitepapers/scram.html
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Regards,
> > > >
> > > > Rajini
> > > >
> > >
> >
>