You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by Roger Hoover <ro...@gmail.com> on 2017/01/23 22:49:51 UTC
Re: [DISCUSS] KIP-84: Support SASL/SCRAM mechanisms
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 <
rajinisivaram@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 <
> rajinisivaram@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 <ju...@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 <
> >> rajinisivaram@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 <ju...@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 <
> >> > > rajinisivaram@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 <ju...@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 <
> >> > > > > 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
> >> > > > > >
> >> > > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Regards,
> >> > > >
> >> > > > Rajini
> >> > > >
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Regards,
> >> >
> >> > Rajini
> >> >
> >>
> >
> >
> >
> > --
> > Regards,
> >
> > Rajini
> >
>
>
>
> --
> Regards,
>
> Rajini
>
Re: [DISCUSS] KIP-84: Support SASL/SCRAM mechanisms
Posted by Roger Hoover <ro...@gmail.com>.
Yes. Thank you, Ismael.
On Wed, Feb 8, 2017 at 2:30 AM, Ismael Juma <is...@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 <ro...@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 <is...@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.hoover@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 <
> > > > rajinisivaram@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 <
> > > > > rajinisivaram@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 <ju...@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 <
> > > > > >> rajinisivaram@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 <ju...@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 <
> > > > > >> > > rajinisivaram@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 <jun@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 <
> > > > > >> > > > > 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
> > > > > >> > > > > >
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > > --
> > > > > >> > > > Regards,
> > > > > >> > > >
> > > > > >> > > > Rajini
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > --
> > > > > >> > Regards,
> > > > > >> >
> > > > > >> > Rajini
> > > > > >> >
> > > > > >>
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Regards,
> > > > > >
> > > > > > Rajini
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Regards,
> > > > >
> > > > > Rajini
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] KIP-84: Support SASL/SCRAM mechanisms
Posted by Ismael Juma <is...@juma.me.uk>.
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 <ro...@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 <is...@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 <ro...@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 <
> > > rajinisivaram@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 <
> > > > rajinisivaram@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 <ju...@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 <
> > > > >> rajinisivaram@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 <ju...@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 <
> > > > >> > > rajinisivaram@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 <ju...@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 <
> > > > >> > > > > 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
> > > > >> > > > > >
> > > > >> > > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > --
> > > > >> > > > Regards,
> > > > >> > > >
> > > > >> > > > Rajini
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > --
> > > > >> > Regards,
> > > > >> >
> > > > >> > Rajini
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Regards,
> > > > >
> > > > > Rajini
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Regards,
> > > >
> > > > Rajini
> > > >
> > >
> >
>
Re: [DISCUSS] KIP-84: Support SASL/SCRAM mechanisms
Posted by Roger Hoover <ro...@gmail.com>.
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 <is...@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 <ro...@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 <
> > rajinisivaram@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 <
> > > rajinisivaram@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 <ju...@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 <
> > > >> rajinisivaram@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 <ju...@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 <
> > > >> > > rajinisivaram@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 <ju...@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 <
> > > >> > > > > 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
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > > --
> > > >> > > > Regards,
> > > >> > > >
> > > >> > > > Rajini
> > > >> > > >
> > > >> > >
> > > >> >
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Regards,
> > > >> >
> > > >> > Rajini
> > > >> >
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Regards,
> > > >
> > > > Rajini
> > > >
> > >
> > >
> > >
> > > --
> > > Regards,
> > >
> > > Rajini
> > >
> >
>
Re: [DISCUSS] KIP-84: Support SASL/SCRAM mechanisms
Posted by Ismael Juma <is...@juma.me.uk>.
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 <ro...@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 <
> rajinisivaram@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 <
> > rajinisivaram@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 <ju...@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 <
> > >> rajinisivaram@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 <ju...@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 <
> > >> > > rajinisivaram@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 <ju...@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 <
> > >> > > > > 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
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > --
> > >> > > > Regards,
> > >> > > >
> > >> > > > Rajini
> > >> > > >
> > >> > >
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Regards,
> > >> >
> > >> > Rajini
> > >> >
> > >>
> > >
> > >
> > >
> > > --
> > > Regards,
> > >
> > > Rajini
> > >
> >
> >
> >
> > --
> > Regards,
> >
> > Rajini
> >
>