You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by Rajini Sivaram <ra...@googlemail.com> on 2016/11/14 13:57:16 UTC
[VOTE] KIP-84: Support SASL SCRAM mechanisms
Hi all,
I would like to initiate the voting process for *KIP-84: Support SASL/SCRAM
mechanisms*:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-84%3A+Support+SASL+SCRAM+mechanisms
This KIP adds support for four SCRAM mechanisms (SHA-224, SHA-256, SHA-384
and SHA-512) for SASL authentication, giving more choice for users to
configure security. When delegation token support is added to Kafka, SCRAM
will also support secure authentication using delegation tokens.
Thank you...
Regards,
Rajini
Re: [VOTE] KIP-84: Support SASL SCRAM mechanisms
Posted by 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
> > > >
> > >
> >
>
Re: [VOTE] KIP-84: Support SASL SCRAM mechanisms
Posted by 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
Posted by Rajini Sivaram <ra...@gmail.com>.
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
Posted by Rajini Sivaram <ra...@googlemail.com>.
Jun,
Any thoughts on reducing the number of mechanisms and supporting only
SCRAM-SHA-256 and SCRAM-SHA-512?
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
> >
>
--
Regards,
Rajini
Re: [VOTE] KIP-84: Support SASL SCRAM mechanisms
Posted by Ismael Juma <is...@juma.me.uk>.
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
Posted by Rajini Sivaram <ra...@googlemail.com>.
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
Posted by Ismael Juma <is...@juma.me.uk>.
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
Re: [VOTE] KIP-84: Support SASL SCRAM mechanisms
Posted by Rajini Sivaram <ra...@googlemail.com>.
Hi Ismael,
Thank you for the review.
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.
2. OK, since it has come up multiple times, I will update the KIP to use a
more verbose format.
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?
On Mon, Nov 28, 2016 at 2:04 PM, Ismael Juma <is...@juma.me.uk> wrote:
> Hi Rajini,
>
> Thanks for the KIP. I am in favour of introducing SCRAM as an additional
> SASL mechanism. A few comments:
>
> 1. Magnus raised the point that cyrus-sasl currently only
> implements SCRAM-SHA-1, so having a larger number of variants will involve
> more work for non-Java clients. Do we really need all of SCRAM-SHA-224,
> SCRAM-SHA-256, SCRAM-SHA-384 and SCRAM-SHA-512?
>
> 2. Like Radai mentioned, it seems a bit weird to use single letter keys.
> The space savings don't seem particularly useful given the size of the
> values. You mentioned that it would not be useful for humans to interpret
> them, but we do expose them via the configs tool. Since we have to add more
> keys, I am also not convinced about the benefit of reusing the same letters
> as for SCRAM messages.
>
> 3. Have we given any thought on whether the znodes storing the
> authentication information should have additional access restrictions (even
> though they are hashed and salted)? Is the assumption that people would
> enable ZK authentication?
>
> Ismael
>
> On Tue, Nov 15, 2016 at 7:25 PM, Rajini Sivaram <
> rajinisivaram@googlemail.com> wrote:
>
> > Radai,
> >
> > I don't have a strong objection to using a more verbose format. But the
> > reasons for choosing the cryptic s=<salt>,t=<storedKey>,... format:
> >
> > 1. Unlike other properties like quotas stored in Zookeeper which need
> to
> > be human readable in order to query the values, these values only need
> > to
> > be parsed by code. The base64-encoded array of bytes don't really mean
> > anything to a human. You would only ever want to check if the user has
> > credentials for a mechanism, you can't really tell what the
> credentials
> > are
> > from the value stored in ZK.
> > 2. Single letter keys save space. Agree, it is not much, but since a
> > more verbose format doesn't add much value, it feels like wasted space
> > in
> > ZK to store long key names for each property for each user for each
> > mechanism.
> > 3. SCRAM authentication messages defined in RFC 5802
> > <https://tools.ietf.org/html/rfc5802> use comma-separated key=value
> > pairs with single letter keys. s=<salt> and i=<iterations> appear
> > exactly
> > like that in SCRAM messages. Server key and stored key are not
> > exchanged,
> > so I chose two unused letters. The same parser used for SCRAM messages
> > is
> > used to parse this persisted value as well since the format is the
> same.
> >
> >
> > On Tue, Nov 15, 2016 at 5:02 PM, radai <ra...@gmail.com>
> wrote:
> >
> > > small nitpick - given that s,t,k and i are used as part of a rather
> large
> > > CSV format, what is the gain in having them be single letter aliases?
> > > in other words - why not salt=... , serverKey=... , storedKey=... ,
> > > iterations=... ?
> > >
> > > On Tue, Nov 15, 2016 at 7:26 AM, Mickael Maison <
> > mickael.maison@gmail.com>
> > > wrote:
> > >
> > > > +1
> > > >
> > > > On Tue, Nov 15, 2016 at 10:57 AM, Rajini Sivaram
> > > > <ra...@googlemail.com> wrote:
> > > > > Jun,
> > > > >
> > > > > Thank you, I have made the updates to the KIP.
> > > > >
> > > > > On Tue, Nov 15, 2016 at 12:34 AM, Jun Rao <ju...@confluent.io>
> wrote:
> > > > >
> > > > >> Hi, Rajini,
> > > > >>
> > > > >> Thanks for the proposal. +1. A few minor comments.
> > > > >>
> > > > >> 30. Could you add that the broker config sasl.enabled.mechanisms
> can
> > > now
> > > > >> take more values?
> > > > >>
> > > > >> 31. Could you document the meaning of s,t,k,i used in
> > > > /config/users/alice
> > > > >> in ZK?
> > > > >>
> > > > >> 32. In the rejected section, could you document why we decided not
> > to
> > > > bump
> > > > >> up the version of SaslHandshakeRequest?
> > > > >>
> > > > >> Jun
> > > > >>
> > > > >>
> > > > >> On Mon, Nov 14, 2016 at 5:57 AM, Rajini Sivaram <
> > > > >> rajinisivaram@googlemail.com> wrote:
> > > > >>
> > > > >> > Hi all,
> > > > >> >
> > > > >> > I would like to initiate the voting process for *KIP-84: Support
> > > > >> SASL/SCRAM
> > > > >> > mechanisms*:
> > > > >> >
> > > > >> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > > > >> > 84%3A+Support+SASL+SCRAM+mechanisms
> > > > >> >
> > > > >> > This KIP adds support for four SCRAM mechanisms (SHA-224,
> SHA-256,
> > > > >> SHA-384
> > > > >> > and SHA-512) for SASL authentication, giving more choice for
> users
> > > to
> > > > >> > configure security. When delegation token support is added to
> > Kafka,
> > > > >> SCRAM
> > > > >> > will also support secure authentication using delegation tokens.
> > > > >> >
> > > > >> > Thank you...
> > > > >> >
> > > > >> > Regards,
> > > > >> >
> > > > >> > Rajini
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Regards,
> > > > >
> > > > > Rajini
> > > >
> > >
> >
> >
> >
> > --
> > Regards,
> >
> > Rajini
> >
>
--
Regards,
Rajini
Re: [VOTE] KIP-84: Support SASL SCRAM mechanisms
Posted by Ismael Juma <is...@juma.me.uk>.
Hi Rajini,
Thanks for the KIP. I am in favour of introducing SCRAM as an additional
SASL mechanism. A few comments:
1. Magnus raised the point that cyrus-sasl currently only
implements SCRAM-SHA-1, so having a larger number of variants will involve
more work for non-Java clients. Do we really need all of SCRAM-SHA-224,
SCRAM-SHA-256, SCRAM-SHA-384 and SCRAM-SHA-512?
2. Like Radai mentioned, it seems a bit weird to use single letter keys.
The space savings don't seem particularly useful given the size of the
values. You mentioned that it would not be useful for humans to interpret
them, but we do expose them via the configs tool. Since we have to add more
keys, I am also not convinced about the benefit of reusing the same letters
as for SCRAM messages.
3. Have we given any thought on whether the znodes storing the
authentication information should have additional access restrictions (even
though they are hashed and salted)? Is the assumption that people would
enable ZK authentication?
Ismael
On Tue, Nov 15, 2016 at 7:25 PM, Rajini Sivaram <
rajinisivaram@googlemail.com> wrote:
> Radai,
>
> I don't have a strong objection to using a more verbose format. But the
> reasons for choosing the cryptic s=<salt>,t=<storedKey>,... format:
>
> 1. Unlike other properties like quotas stored in Zookeeper which need to
> be human readable in order to query the values, these values only need
> to
> be parsed by code. The base64-encoded array of bytes don't really mean
> anything to a human. You would only ever want to check if the user has
> credentials for a mechanism, you can't really tell what the credentials
> are
> from the value stored in ZK.
> 2. Single letter keys save space. Agree, it is not much, but since a
> more verbose format doesn't add much value, it feels like wasted space
> in
> ZK to store long key names for each property for each user for each
> mechanism.
> 3. SCRAM authentication messages defined in RFC 5802
> <https://tools.ietf.org/html/rfc5802> use comma-separated key=value
> pairs with single letter keys. s=<salt> and i=<iterations> appear
> exactly
> like that in SCRAM messages. Server key and stored key are not
> exchanged,
> so I chose two unused letters. The same parser used for SCRAM messages
> is
> used to parse this persisted value as well since the format is the same.
>
>
> On Tue, Nov 15, 2016 at 5:02 PM, radai <ra...@gmail.com> wrote:
>
> > small nitpick - given that s,t,k and i are used as part of a rather large
> > CSV format, what is the gain in having them be single letter aliases?
> > in other words - why not salt=... , serverKey=... , storedKey=... ,
> > iterations=... ?
> >
> > On Tue, Nov 15, 2016 at 7:26 AM, Mickael Maison <
> mickael.maison@gmail.com>
> > wrote:
> >
> > > +1
> > >
> > > On Tue, Nov 15, 2016 at 10:57 AM, Rajini Sivaram
> > > <ra...@googlemail.com> wrote:
> > > > Jun,
> > > >
> > > > Thank you, I have made the updates to the KIP.
> > > >
> > > > On Tue, Nov 15, 2016 at 12:34 AM, Jun Rao <ju...@confluent.io> wrote:
> > > >
> > > >> Hi, Rajini,
> > > >>
> > > >> Thanks for the proposal. +1. A few minor comments.
> > > >>
> > > >> 30. Could you add that the broker config sasl.enabled.mechanisms can
> > now
> > > >> take more values?
> > > >>
> > > >> 31. Could you document the meaning of s,t,k,i used in
> > > /config/users/alice
> > > >> in ZK?
> > > >>
> > > >> 32. In the rejected section, could you document why we decided not
> to
> > > bump
> > > >> up the version of SaslHandshakeRequest?
> > > >>
> > > >> Jun
> > > >>
> > > >>
> > > >> On Mon, Nov 14, 2016 at 5:57 AM, Rajini Sivaram <
> > > >> rajinisivaram@googlemail.com> wrote:
> > > >>
> > > >> > Hi all,
> > > >> >
> > > >> > I would like to initiate the voting process for *KIP-84: Support
> > > >> SASL/SCRAM
> > > >> > mechanisms*:
> > > >> >
> > > >> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > > >> > 84%3A+Support+SASL+SCRAM+mechanisms
> > > >> >
> > > >> > This KIP adds support for four SCRAM mechanisms (SHA-224, SHA-256,
> > > >> SHA-384
> > > >> > and SHA-512) for SASL authentication, giving more choice for users
> > to
> > > >> > configure security. When delegation token support is added to
> Kafka,
> > > >> SCRAM
> > > >> > will also support secure authentication using delegation tokens.
> > > >> >
> > > >> > Thank you...
> > > >> >
> > > >> > Regards,
> > > >> >
> > > >> > Rajini
> > > >> >
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Regards,
> > > >
> > > > Rajini
> > >
> >
>
>
>
> --
> Regards,
>
> Rajini
>
Re: [VOTE] KIP-84: Support SASL SCRAM mechanisms
Posted by Rajini Sivaram <ra...@googlemail.com>.
Radai,
I don't have a strong objection to using a more verbose format. But the
reasons for choosing the cryptic s=<salt>,t=<storedKey>,... format:
1. Unlike other properties like quotas stored in Zookeeper which need to
be human readable in order to query the values, these values only need to
be parsed by code. The base64-encoded array of bytes don't really mean
anything to a human. You would only ever want to check if the user has
credentials for a mechanism, you can't really tell what the credentials are
from the value stored in ZK.
2. Single letter keys save space. Agree, it is not much, but since a
more verbose format doesn't add much value, it feels like wasted space in
ZK to store long key names for each property for each user for each
mechanism.
3. SCRAM authentication messages defined in RFC 5802
<https://tools.ietf.org/html/rfc5802> use comma-separated key=value
pairs with single letter keys. s=<salt> and i=<iterations> appear exactly
like that in SCRAM messages. Server key and stored key are not exchanged,
so I chose two unused letters. The same parser used for SCRAM messages is
used to parse this persisted value as well since the format is the same.
On Tue, Nov 15, 2016 at 5:02 PM, radai <ra...@gmail.com> wrote:
> small nitpick - given that s,t,k and i are used as part of a rather large
> CSV format, what is the gain in having them be single letter aliases?
> in other words - why not salt=... , serverKey=... , storedKey=... ,
> iterations=... ?
>
> On Tue, Nov 15, 2016 at 7:26 AM, Mickael Maison <mi...@gmail.com>
> wrote:
>
> > +1
> >
> > On Tue, Nov 15, 2016 at 10:57 AM, Rajini Sivaram
> > <ra...@googlemail.com> wrote:
> > > Jun,
> > >
> > > Thank you, I have made the updates to the KIP.
> > >
> > > On Tue, Nov 15, 2016 at 12:34 AM, Jun Rao <ju...@confluent.io> wrote:
> > >
> > >> Hi, Rajini,
> > >>
> > >> Thanks for the proposal. +1. A few minor comments.
> > >>
> > >> 30. Could you add that the broker config sasl.enabled.mechanisms can
> now
> > >> take more values?
> > >>
> > >> 31. Could you document the meaning of s,t,k,i used in
> > /config/users/alice
> > >> in ZK?
> > >>
> > >> 32. In the rejected section, could you document why we decided not to
> > bump
> > >> up the version of SaslHandshakeRequest?
> > >>
> > >> Jun
> > >>
> > >>
> > >> On Mon, Nov 14, 2016 at 5:57 AM, Rajini Sivaram <
> > >> rajinisivaram@googlemail.com> wrote:
> > >>
> > >> > Hi all,
> > >> >
> > >> > I would like to initiate the voting process for *KIP-84: Support
> > >> SASL/SCRAM
> > >> > mechanisms*:
> > >> >
> > >> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > >> > 84%3A+Support+SASL+SCRAM+mechanisms
> > >> >
> > >> > This KIP adds support for four SCRAM mechanisms (SHA-224, SHA-256,
> > >> SHA-384
> > >> > and SHA-512) for SASL authentication, giving more choice for users
> to
> > >> > configure security. When delegation token support is added to Kafka,
> > >> SCRAM
> > >> > will also support secure authentication using delegation tokens.
> > >> >
> > >> > Thank you...
> > >> >
> > >> > Regards,
> > >> >
> > >> > Rajini
> > >> >
> > >>
> > >
> > >
> > >
> > > --
> > > Regards,
> > >
> > > Rajini
> >
>
--
Regards,
Rajini
Re: [VOTE] KIP-84: Support SASL SCRAM mechanisms
Posted by radai <ra...@gmail.com>.
small nitpick - given that s,t,k and i are used as part of a rather large
CSV format, what is the gain in having them be single letter aliases?
in other words - why not salt=... , serverKey=... , storedKey=... ,
iterations=... ?
On Tue, Nov 15, 2016 at 7:26 AM, Mickael Maison <mi...@gmail.com>
wrote:
> +1
>
> On Tue, Nov 15, 2016 at 10:57 AM, Rajini Sivaram
> <ra...@googlemail.com> wrote:
> > Jun,
> >
> > Thank you, I have made the updates to the KIP.
> >
> > On Tue, Nov 15, 2016 at 12:34 AM, Jun Rao <ju...@confluent.io> wrote:
> >
> >> Hi, Rajini,
> >>
> >> Thanks for the proposal. +1. A few minor comments.
> >>
> >> 30. Could you add that the broker config sasl.enabled.mechanisms can now
> >> take more values?
> >>
> >> 31. Could you document the meaning of s,t,k,i used in
> /config/users/alice
> >> in ZK?
> >>
> >> 32. In the rejected section, could you document why we decided not to
> bump
> >> up the version of SaslHandshakeRequest?
> >>
> >> Jun
> >>
> >>
> >> On Mon, Nov 14, 2016 at 5:57 AM, Rajini Sivaram <
> >> rajinisivaram@googlemail.com> wrote:
> >>
> >> > Hi all,
> >> >
> >> > I would like to initiate the voting process for *KIP-84: Support
> >> SASL/SCRAM
> >> > mechanisms*:
> >> >
> >> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> >> > 84%3A+Support+SASL+SCRAM+mechanisms
> >> >
> >> > This KIP adds support for four SCRAM mechanisms (SHA-224, SHA-256,
> >> SHA-384
> >> > and SHA-512) for SASL authentication, giving more choice for users to
> >> > configure security. When delegation token support is added to Kafka,
> >> SCRAM
> >> > will also support secure authentication using delegation tokens.
> >> >
> >> > Thank you...
> >> >
> >> > Regards,
> >> >
> >> > Rajini
> >> >
> >>
> >
> >
> >
> > --
> > Regards,
> >
> > Rajini
>
Re: [VOTE] KIP-84: Support SASL SCRAM mechanisms
Posted by Mickael Maison <mi...@gmail.com>.
+1
On Tue, Nov 15, 2016 at 10:57 AM, Rajini Sivaram
<ra...@googlemail.com> wrote:
> Jun,
>
> Thank you, I have made the updates to the KIP.
>
> On Tue, Nov 15, 2016 at 12:34 AM, Jun Rao <ju...@confluent.io> wrote:
>
>> Hi, Rajini,
>>
>> Thanks for the proposal. +1. A few minor comments.
>>
>> 30. Could you add that the broker config sasl.enabled.mechanisms can now
>> take more values?
>>
>> 31. Could you document the meaning of s,t,k,i used in /config/users/alice
>> in ZK?
>>
>> 32. In the rejected section, could you document why we decided not to bump
>> up the version of SaslHandshakeRequest?
>>
>> Jun
>>
>>
>> On Mon, Nov 14, 2016 at 5:57 AM, Rajini Sivaram <
>> rajinisivaram@googlemail.com> wrote:
>>
>> > Hi all,
>> >
>> > I would like to initiate the voting process for *KIP-84: Support
>> SASL/SCRAM
>> > mechanisms*:
>> >
>> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
>> > 84%3A+Support+SASL+SCRAM+mechanisms
>> >
>> > This KIP adds support for four SCRAM mechanisms (SHA-224, SHA-256,
>> SHA-384
>> > and SHA-512) for SASL authentication, giving more choice for users to
>> > configure security. When delegation token support is added to Kafka,
>> SCRAM
>> > will also support secure authentication using delegation tokens.
>> >
>> > Thank you...
>> >
>> > Regards,
>> >
>> > Rajini
>> >
>>
>
>
>
> --
> Regards,
>
> Rajini
Re: [VOTE] KIP-84: Support SASL SCRAM mechanisms
Posted by Edoardo Comar <EC...@uk.ibm.com>.
+1 (non-binding)
--------------------------------------------------
Edoardo Comar
IBM MessageHub
ecomar@uk.ibm.com
IBM UK Ltd, Hursley Park, SO21 2JN
IBM United Kingdom Limited Registered in England and Wales with number
741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6
3AU
From: Rajini Sivaram <ra...@googlemail.com>
To: dev@kafka.apache.org
Date: 15/11/2016 11:00
Subject: Re: [VOTE] KIP-84: Support SASL SCRAM mechanisms
Jun,
Thank you, I have made the updates to the KIP.
On Tue, Nov 15, 2016 at 12:34 AM, Jun Rao <ju...@confluent.io> wrote:
> Hi, Rajini,
>
> Thanks for the proposal. +1. A few minor comments.
>
> 30. Could you add that the broker config sasl.enabled.mechanisms can now
> take more values?
>
> 31. Could you document the meaning of s,t,k,i used in
/config/users/alice
> in ZK?
>
> 32. In the rejected section, could you document why we decided not to
bump
> up the version of SaslHandshakeRequest?
>
> Jun
>
>
> On Mon, Nov 14, 2016 at 5:57 AM, Rajini Sivaram <
> rajinisivaram@googlemail.com> wrote:
>
> > Hi all,
> >
> > I would like to initiate the voting process for *KIP-84: Support
> SASL/SCRAM
> > mechanisms*:
> >
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > 84%3A+Support+SASL+SCRAM+mechanisms
> >
> > This KIP adds support for four SCRAM mechanisms (SHA-224, SHA-256,
> SHA-384
> > and SHA-512) for SASL authentication, giving more choice for users to
> > configure security. When delegation token support is added to Kafka,
> SCRAM
> > will also support secure authentication using delegation tokens.
> >
> > Thank you...
> >
> > Regards,
> >
> > Rajini
> >
>
--
Regards,
Rajini
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: [VOTE] KIP-84: Support SASL SCRAM mechanisms
Posted by Rajini Sivaram <ra...@googlemail.com>.
Jun,
Thank you, I have made the updates to the KIP.
On Tue, Nov 15, 2016 at 12:34 AM, Jun Rao <ju...@confluent.io> wrote:
> Hi, Rajini,
>
> Thanks for the proposal. +1. A few minor comments.
>
> 30. Could you add that the broker config sasl.enabled.mechanisms can now
> take more values?
>
> 31. Could you document the meaning of s,t,k,i used in /config/users/alice
> in ZK?
>
> 32. In the rejected section, could you document why we decided not to bump
> up the version of SaslHandshakeRequest?
>
> Jun
>
>
> On Mon, Nov 14, 2016 at 5:57 AM, Rajini Sivaram <
> rajinisivaram@googlemail.com> wrote:
>
> > Hi all,
> >
> > I would like to initiate the voting process for *KIP-84: Support
> SASL/SCRAM
> > mechanisms*:
> >
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > 84%3A+Support+SASL+SCRAM+mechanisms
> >
> > This KIP adds support for four SCRAM mechanisms (SHA-224, SHA-256,
> SHA-384
> > and SHA-512) for SASL authentication, giving more choice for users to
> > configure security. When delegation token support is added to Kafka,
> SCRAM
> > will also support secure authentication using delegation tokens.
> >
> > Thank you...
> >
> > Regards,
> >
> > Rajini
> >
>
--
Regards,
Rajini
Re: [VOTE] KIP-84: Support SASL SCRAM mechanisms
Posted by Jun Rao <ju...@confluent.io>.
Hi, Rajini,
Thanks for the proposal. +1. A few minor comments.
30. Could you add that the broker config sasl.enabled.mechanisms can now
take more values?
31. Could you document the meaning of s,t,k,i used in /config/users/alice
in ZK?
32. In the rejected section, could you document why we decided not to bump
up the version of SaslHandshakeRequest?
Jun
On Mon, Nov 14, 2016 at 5:57 AM, Rajini Sivaram <
rajinisivaram@googlemail.com> wrote:
> Hi all,
>
> I would like to initiate the voting process for *KIP-84: Support SASL/SCRAM
> mechanisms*:
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> 84%3A+Support+SASL+SCRAM+mechanisms
>
> This KIP adds support for four SCRAM mechanisms (SHA-224, SHA-256, SHA-384
> and SHA-512) for SASL authentication, giving more choice for users to
> configure security. When delegation token support is added to Kafka, SCRAM
> will also support secure authentication using delegation tokens.
>
> Thank you...
>
> Regards,
>
> Rajini
>
Re: [VOTE] KIP-84: Support SASL SCRAM mechanisms
Posted by Rajini Sivaram <ra...@googlemail.com>.
Another committer vote is needed for this to go through. Anyone have time
to review?
Thank you!
On Tue, Nov 15, 2016 at 6:26 PM, Gwen Shapira <gw...@confluent.io> wrote:
> +1
>
> On Mon, Nov 14, 2016 at 5:57 AM, Rajini Sivaram
> <ra...@googlemail.com> wrote:
> > Hi all,
> >
> > I would like to initiate the voting process for *KIP-84: Support
> SASL/SCRAM
> > mechanisms*:
> >
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> 84%3A+Support+SASL+SCRAM+mechanisms
> >
> > This KIP adds support for four SCRAM mechanisms (SHA-224, SHA-256,
> SHA-384
> > and SHA-512) for SASL authentication, giving more choice for users to
> > configure security. When delegation token support is added to Kafka,
> SCRAM
> > will also support secure authentication using delegation tokens.
> >
> > Thank you...
> >
> > Regards,
> >
> > Rajini
>
>
>
> --
> Gwen Shapira
> Product Manager | Confluent
> 650.450.2760 | @gwenshap
> Follow us: Twitter | blog
>
--
Regards,
Rajini
Re: [VOTE] KIP-84: Support SASL SCRAM mechanisms
Posted by Gwen Shapira <gw...@confluent.io>.
+1
On Mon, Nov 14, 2016 at 5:57 AM, Rajini Sivaram
<ra...@googlemail.com> wrote:
> Hi all,
>
> I would like to initiate the voting process for *KIP-84: Support SASL/SCRAM
> mechanisms*:
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-84%3A+Support+SASL+SCRAM+mechanisms
>
> This KIP adds support for four SCRAM mechanisms (SHA-224, SHA-256, SHA-384
> and SHA-512) for SASL authentication, giving more choice for users to
> configure security. When delegation token support is added to Kafka, SCRAM
> will also support secure authentication using delegation tokens.
>
> Thank you...
>
> Regards,
>
> Rajini
--
Gwen Shapira
Product Manager | Confluent
650.450.2760 | @gwenshap
Follow us: Twitter | blog