kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Magnus Edenhill <mag...@edenhill.se>
Subject Re: [DISCUSS] KIP-84: Support SASL/SCRAM mechanisms
Date Tue, 08 Nov 2016 15:39:47 GMT
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 <rajinisivaram@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 <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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message