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 some fallback mechanism (PLAIN, GSSAPI, ..) * Send SaslHandshakeRequest with selected mechanism * Broker returns Ok, or error if the mechanism is unsupported or disabled. * On error, use some fallback mechanism. [*] Without SaslHandshake version bump: * Client sends SaslHandshake mechanism=SCRAM * Broker returns Ok, or error if the mechanism is unsupported or disabled. * On error, use some fallback mechanism [*] This goes to show that in both scenarios the client will need some logic to handle an unsupported/disabled mechanism, so bumping the SaslHandshake version doesn't really help much (unless the API version reflects the configured authenticator). [*]: I dont think any client implements auth mechanism fallback and I have yet to see a real-world use-case for it, so if the mechanism configured on the client isnt available on the broker that is typically a terminal error. And for error reporting to the user: all it needs to say is that the client's configured mechanism is not available on the broker, but these enabled_mechanisms are. My two cents, Magnus 2016-11-08 13:42 GMT+01:00 Rajini Sivaram <rajinisiva...@googlemail.com>: > 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 >
