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 <ism...@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 <rajinisiva...@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 <ism...@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 < > > > rajinisiva...@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 <ism...@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 < > > > > > rajinisiva...@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 > > > > > > > > > >
