kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajini Sivaram <rajinisiva...@googlemail.com>
Subject Re: [DISCUSS] KIP-84: Support SASL/SCRAM mechanisms
Date Wed, 26 Oct 2016 11:35:26 GMT
Hi Jun,

Thank you for reviewing the KIP. Answers below:

   1. Yes, agree, Updated KIP.
   2. User specifies a password and iteration count. kaka-configs.sh
   generates a random salt and then generates StoredKey and ServerKey for that
   password using the same message formatter implementation used for SCRAM
   authentication. I have added some more detail to the KIP (
   Does that answer the question?
   3. I started off thinking just one (SCRAM-SHA-256) and then thought
   another one is required to make sure that the implementation can cope with
   multiple SCRAM mechanisms. But actually you are right, we can support all.
   I haven't added the old md2/md5 mechanisms that aren't very secure, but I
   have included all the SHA algorithms.
   4. Since credentials are only required when a connection is made, it
   feels like we can just read the latest value from ZK rather than cache all
   users and keep them updated. Having said that, we can always add caching
   later if we find that the overhead of reading from ZK every time is too
   expensive. Since caching doesn't change any externals, this can be done in
   a JIRA later - would that be ok?
   5. Thanks, updated. I have changed the property names to include
   mechanism. To avoid four separate properties per mechanism in ZK, I have
   changed the format to use a single property (lower-case mechanism name)
   with four values concatenated in a format similar to SCRAM messages.

Do you think storing SCRAM credentials in /config/users/<encoded-user>
along with existing quota properties is okay? Or should they be under a
different path (eg. /config/credentials/<encoded-user>)? Or should they be
on a completely different path like ACLs with a separate tool instead of
reusing kaka-configs.sh?

Thank you,


On Tue, Oct 25, 2016 at 11:55 PM, Jun Rao <jun@confluent.io> wrote:

> Hi, Rajini,
> Thanks for the proposal. Looks good overall and seems quite useful (e.g.
> for supporting delegation tokens). A few comments/questions below.
> 1. For the ZK data format change, should we use the same convention as in
> KIP-55 to use encoded user name (i.e., /config/users/<encoded-user1>)?
> 2. For tooling, could you describe how user typically generates
> scam_server_key and scram_stored_key to be used by kafka-config.sh?
> 3. Is there a particular reason to only support sha1 and sha128? Should we
> support more hashes listed below in the future?
> http://www.iana.org/assignments/hash-function-
> text-names/hash-function-text-names.xhtml
> 4. Is there a reason not to cache user credentials in the broker? The
> dynamic config mechanism already supports loading configs into broker's
> cache. Checking credentials from broker's cache is more efficient than
> reading from ZK each time.
> 5. Typo "scram_iteration-4096" (= instead of -).
> Thanks,
> Jun
> On Tue, Oct 4, 2016 at 6:43 AM, Rajini Sivaram <
> rajinisivaram@googlemail.com
> > wrote:
> > Hi all,
> >
> > I have just created KIP-84 to add SCRAM-SHA-1 and SCRAM-SHA-256 SASL
> > mechanisms to Kafka:
> >
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > 84%3A+Support+SASL+SCRAM+mechanisms
> >
> >
> > Comments and suggestions are welcome.
> >
> > Thank you...
> >
> > Regards,
> >
> > Rajini
> >



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message