Sorry for the late question but is there a reason to choose SHA-1 and SHA-256 instead of bcrypt?
https://codahale.com/how-to-safely-store-a-password/ On Fri, Nov 11, 2016 at 5:30 AM, Rajini Sivaram < rajinisiva...@googlemail.com> wrote: > I think all the comments and suggestions on this thread have now been > incorporated into the KIP. If there are no objections, I will start the > voting process on Monday. > > Regards, > > Rajini > > On Tue, Nov 8, 2016 at 9:20 PM, Rajini Sivaram < > rajinisiva...@googlemail.com > > wrote: > > > Jun, > > > > Have added a sub-section on delegation token support to the KIP. > > > > Thank you, > > > > Rajini > > > > On Tue, Nov 8, 2016 at 8:07 PM, Jun Rao <j...@confluent.io> wrote: > > > >> Hi, Rajini, > >> > >> That makes sense. Could you document this potential future extension in > >> the > >> KIP? > >> > >> Jun > >> > >> On Tue, Nov 8, 2016 at 11:17 AM, Rajini Sivaram < > >> rajinisiva...@googlemail.com> wrote: > >> > >> > Jun, > >> > > >> > 11. SCRAM messages have an optional extensions field which is a list > of > >> > key=value pairs. We can add an extension key to the first client > >> message to > >> > indicate delegation token. Broker can then obtain credentials and > >> principal > >> > using a different code path for delegation tokens. > >> > > >> > On Tue, Nov 8, 2016 at 6:38 PM, Jun Rao <j...@confluent.io> wrote: > >> > > >> > > Magnus, > >> > > > >> > > Thanks for the input. If you don't feel strongly the need to bump up > >> the > >> > > version of SaslHandshake, we can leave the version unchanged. > >> > > > >> > > Rajini, > >> > > > >> > > 11. Yes, we could send the HMAC as the SCRAM password for the > >> delegation > >> > > token. Do we need something to indicate that this SCRAM token is > >> special > >> > > (i.e., delegation token) so that we can generate the correct > >> > > KafkaPrincipal? The delegation token logic can be added later. I am > >> > asking > >> > > just so that we have enough in the design of SCRAM to add the > >> delegation > >> > > token logic later. > >> > > > >> > > Thanks, > >> > > > >> > > Jun > >> > > > >> > > > >> > > On Tue, Nov 8, 2016 at 4:42 AM, Rajini Sivaram < > >> > > rajinisiva...@googlemail.com > >> > > > wrote: > >> > > > >> > > > Hi Jun, > >> > > > > >> > > > 10. *s=<salt>* and *i=<iterations>* come from the SCRAM standard > >> (they > >> > > are > >> > > > transferred during SCRAM auth). Scram messages look like (for > >> example) > >> > > > *r=<nonce>,s=<salt>,i=<iterations>*. StoredKey and ServerKey and > >> not > >> > > > transferred in SCRAM messages, so I picked two keys that are > unused > >> in > >> > > > SCRAM. > >> > > > > >> > > > 11. SCRAM (like DIGEST-MD5 or PLAIN) uses a shared secret/password > >> for > >> > > > authentication along with a username and an optional > >> authorization-id. > >> > > > Kafka uses the username as the identity (Kafka principal) for > >> > > > authentication and authorization. KIP-48 doesn't mention > >> KafkaPrincipal > >> > > in > >> > > > the section "Authentication using Token", but a delegation token > is > >> > > > associated with a Kafka principal. Since delegation tokens are > >> acquired > >> > > on > >> > > > behalf of a KafkaPrincipal and the principal is included in the > >> token > >> > as > >> > > > the token owner, clients authenticating with delegation tokens > >> could > >> > use > >> > > > the token owner as username and the token HMAC as shared > >> > secret/password. > >> > > > > >> > > > If necessary, any other form of token identifier may be used as > >> > username > >> > > as > >> > > > well as long as it contains sufficient information for the broker > to > >> > > > retrieve/compute the principal and HMAC for authentication. The > >> server > >> > > > callback handler can be updated when delegation tokens are > >> implemented > >> > to > >> > > > generate Kafka principal accordingly. > >> > > > > >> > > > > >> > > > On Tue, Nov 8, 2016 at 1:03 AM, Jun Rao <j...@confluent.io> wrote: > >> > > > > >> > > > > Hi, Rajini, > >> > > > > > >> > > > > A couple of other questions on the KIP. > >> > > > > > >> > > > > 10. For the config values stored in ZK, are those keys (s, t, k, > >> i, > >> > > etc) > >> > > > > stored under scram-sha-256 standard? > >> > > > > > >> > > > > 11. Could KIP-48 (delegation token) use this KIP to send > >> delegation > >> > > > tokens? > >> > > > > In KIP-48, the client sends a HMAC as the delegation token to > the > >> > > server. > >> > > > > Not sure how this gets mapped to the username/password in this > >> KIP. > >> > > > > > >> > > > > Thanks, > >> > > > > > >> > > > > Jun > >> > > > > > >> > > > > On Tue, Oct 4, 2016 at 6:43 AM, Rajini Sivaram < > >> > > > > rajinisiva...@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 > >> > > > > > > >> > > > > > >> > > > > >> > > > > >> > > > > >> > > > -- > >> > > > Regards, > >> > > > > >> > > > Rajini > >> > > > > >> > > > >> > > >> > > >> > > >> > -- > >> > Regards, > >> > > >> > Rajini > >> > > >> > > > > > > > > -- > > Regards, > > > > Rajini > > > > > > -- > Regards, > > Rajini >
