Yes. Thank you, Ismael. On Wed, Feb 8, 2017 at 2:30 AM, Ismael Juma <ism...@juma.me.uk> wrote:
> Hi Roger, > > Sorry for the delay. SCRAM is specified by: > > https://tools.ietf.org/html/rfc5802 > > The following quote is relevant: > > A SCRAM mechanism name is a string "SCRAM-" followed by the > > uppercased name of the underlying hash function taken from the IANA > > "Hash Function Textual Names" registry (see http://www.iana.org), > > optionally followed by the suffix "-PLUS" (see below) > > > And: > > "md2" 1.2.840.113549.2.2 [RFC3279] > > "md5" 1.2.840.113549.2.5 [RFC3279] > > "sha-1" 1.3.14.3.2.26 [RFC3279] > > "sha-224" 2.16.840.1.101.3.4.2.4 [RFC4055] > > "sha-256" 2.16.840.1.101.3.4.2.1 [RFC4055] > > "sha-384" 2.16.840.1.101.3.4.2.2 [RFC4055] > > "sha-512" 2.16.840.1.101.3.4.2.3 [RFC4055] > > > https://www.iana.org/assignments/hash-function- > text-names/hash-function-text-names.xhtml > > As you see, bcrypt is not an option for the current spec. The naming of the > mechanisms would be a bit misleading if support for bcrypt was added > (SCRAM-PKBDF2-SHA512, SCRAM-BCRYPT*, etc. would be better). > > Does that make sense? > > Ismael > > On Tue, Jan 24, 2017 at 7:26 PM, Roger Hoover <roger.hoo...@gmail.com> > wrote: > > > Thanks, Ismael. Just curious, why does it not make sense to do bcrypt > > it in the context of SCRAM? > > > > On Mon, Jan 23, 2017 at 3:54 PM, Ismael Juma <ism...@juma.me.uk> wrote: > > > > > Hi Roger, > > > > > > SCRAM uses the PBKDF2 mechanism, here's a comparison between PBKDF2 and > > > bcrypt: > > > > > > http://security.stackexchange.com/questions/4781/do-any-secu > > > rity-experts-recommend-bcrypt-for-password-storage/6415#6415 > > > > > > It may be worth supporting bcrypt, but not sure it would make sense to > do > > > it in the context of SCRAM. > > > > > > A minor correction: the KIP includes SCRAM-SHA-256 and SCRAM-SHA-512 > (not > > > SCRAM-SHA-1). > > > > > > Ismael > > > > > > On Mon, Jan 23, 2017 at 10:49 PM, Roger Hoover <roger.hoo...@gmail.com > > > > > wrote: > > > > > > > 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 > > > > > > > > > > > > > > >
