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 <rajinisiva...@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 <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 >
