Yes. Thank you, Ismael.
On Wed, Feb 8, 2017 at 2:30 AM, Ismael Juma 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
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 (
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 wrote:
> Hi Roger,
>
> SCRAM uses the PBKDF2 mechanism, here's a comparison between PBKDF2 and
> bcrypt:
>
> http://security.stackexchange.com/questions
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
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 h
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 wrote:
> Jun,
>
> Have added a sub-section on delegation token
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 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 Sivar
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 ad
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, 20
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
Hey,
I'm probably going to argue against bumping the SaslHandshake version, it
is redundant to the existing SaslHandshakeResponse.enabled_mechanisms field.
With SaslHandshake version bump:
* Client performs ApiVersionRequest
* If SaslHandshake >= v1: use SCRAM
* If SaslHandshake < v1: use
Hi Jun,
10. *s=* and *i=* come from the SCRAM standard (they are
transferred during SCRAM auth). Scram messages look like (for example)
*r=,s=,i=*. 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) us
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
I think Magnus brought up the point of bumping up the version of
SaslHandshakeRequest
during the discussion of KIP-35. A broker may be capable of supporting a
list of SASL mechanisms X and may be enabling a list of SASL mechanisms Y.
Y will be a subset of X. Now, from a client's perspective, it may
Agree with Rajini on not incrementing the protocol version. As brokers are
returning the list of supported mechanisms don't think it warrants a
protocol version bump.
Thanks,
Harsha
On Thu, Nov 3, 2016 at 7:59 AM Rajini Sivaram
wrote:
> Ismael,
>
> 2) I left out MD5 because it is insecure, but
Ismael,
2) I left out MD5 because it is insecure, but thought of keeping SHA-1
since it is supported by most services that support SCRAM today. Since
there is no actual requirement to support SHA-1 and we don't really want to
store credentials in Zookeeper using SHA-1, it makes sense not to suppor
Hi all,
I'm currently with limited internet access so I have not done a proper
review of the KIP, my apologies. A couple of thoughts:
1. I agree with Rajini and I don't see the value in bumping the protocol
version in this case. As Rajini said, the enabled mechanisms are
independent of the broker
I don't have a strong objection to bumping up SaslHandshakeRequest version,
though I am still not convinced of the usefulness. I do agree that KIP-35
should be standard way to determine client/broker compatibility. But I am
not sure ApiVersionsRequest is a good fit for clients to choose a SASL
mech
I think the bump isn't strictly required, but if the client is KIP-35
aware, it can proactively choose a compatible SASL mechanism based on its
initial ApiVersionRequest and avoid an extra connection round trip when
there are client/broker version differences. Without this, a newer client
would hav
Gwen,
I had thought the same too and hence I am assuming that Java clients could
simply use SaslHandshakeRequest. SaslHandshakeRequest returns the list of
mechanisms enabled in the broker. I think Jun's point was that by
incrementing the version of SaslHandshakeRequest, clients can use
ApiVersions
Wait, I thought SaslHandshakeResponse includes a list of mechanisms
supported, so I'm not sure why we need to bump the version?
I expect clients will send SaslHandshakeRequest_V0, see which mechanisms
are supported and make a call based on that? Which means KIP-35 is not
required in that case? Am
Jun,
I have added the following text to the KIP. Does this match your
expectation?
*SaslHandshakeRequest version will be increased from 0 to 1 so that clients
can determine if the broker is capable of supporting SCRAM mechanisms using
ApiVersionsRequest. Java clients will not be updated to use
Ap
Hi, Rajini,
One more thing. It seems that we should bump up the version of
SaslHandshakeRequest? This way, the client can figure out which SASL
mechanisms the broker is capable of supporting through ApiVersionRequest.
We discussed this briefly as part of KIP-43.
Thanks,
Jun
On Tue, Nov 1, 201
If there are no more comments, I will start vote on this KIP later this
week. In the meantime, please feel free to post any feedback or
suggestions. Initial implementation is here:
https://github.com/apache/kafka/pull/2086.
Thank you,
Rajini
On Thu, Oct 27, 2016 at 11:18 AM, Rajini Sivaram <
raj
Jun,
4) Agree, it does make the implementation simpler. Updated KIP.
5) Thank you, that looks neater. Updated KIP.
On Wed, Oct 26, 2016 at 6:59 PM, Jun Rao wrote:
> Hi, Rajini,
>
> Thanks for the reply.
>
> 4. Implementation wise, it seems to me that it's simpler to read from the
> cache than r
Hi, Rajini,
Thanks for the reply.
4. Implementation wise, it seems to me that it's simpler to read from the
cache than reading directly from ZK since the config manager already
propagates all config changes through ZK. Also, it's probably a good idea
to limit the places in the code base that dire
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 u
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/)?
2. For tooling
I have created KIP-86 (
https://cwiki.apache.org/confluence/display/KAFKA/KIP-86%3A+Configurable+SASL+callback+handlers)
to enable pluggable credential providers.
On Mon, Oct 10, 2016 at 7:40 PM, Rajini Sivaram <
rajinisiva...@googlemail.com> wrote:
> Gwen,
>
> Thank you, will raise a separate KI
Gwen,
Thank you, will raise a separate KIP for a pluggable interface.
On Mon, Oct 10, 2016 at 5:55 PM, Gwen Shapira wrote:
> I think it is fine to break the password store to an interface in a
> separate KIP. I actually love the idea of smaller KIPs dealing with
> more specific functionality. I
I think it is fine to break the password store to an interface in a
separate KIP. I actually love the idea of smaller KIPs dealing with
more specific functionality. I just wasn't clear why it was rejected.
Thank you for clarifying. I'm happy with current proposal.
Gwen
On Mon, Oct 10, 2016 at 2:
Gwen,
Thank you for reviewing the KIP.
There has been interest in making the password verification in SASL/PLAIN
more pluggable. So I think it makes sense to have a pluggable interface
that can be adopted for any SASL mechanism rather than just SCRAM. With the
current proposal, you can plugin ano
Can you talk more about rejecting the option of making the password
store pluggable? I am a bit uncomfortable with making ZK the one and
only password store...
On Tue, Oct 4, 2016 at 6:43 AM, Rajini Sivaram
wrote:
> Hi all,
>
> I have just created KIP-84 to add SCRAM-SHA-1 and SCRAM-SHA-256 SASL
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
34 matches
Mail list logo
