kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajini Sivaram <rajinisiva...@googlemail.com>
Subject Re: [DISCUSS] KIP-84: Support SASL/SCRAM mechanisms
Date Tue, 08 Nov 2016 19:17:34 GMT
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 <jun@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

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