The only pending update for the KIP is to write up the protocol changes like we've it KIP-4. I'll update the wiki.
On Thu, Sep 15, 2016 at 4:27 PM Ashish Singh <asi...@cloudera.com> wrote: > I think we decided to not support secret rotation, I guess this can be > stated clearly on the KIP. Also, more details on how clients will perform > token distribution and how CLI will look like will be helpful. > > On Thu, Sep 15, 2016 at 3:20 PM, Gwen Shapira <g...@confluent.io> wrote: > > > Hi Guys, > > > > This discussion was dead for a while. Are there still contentious > > points? If not, why are there no votes? > > > > On Tue, Aug 23, 2016 at 1:26 PM, Jun Rao <j...@confluent.io> wrote: > > > Ashish, > > > > > > Yes, I will send out a KIP invite for next week to discuss KIP-48 and > > other > > > remaining KIPs. > > > > > > Thanks, > > > > > > Jun > > > > > > On Tue, Aug 23, 2016 at 1:22 PM, Ashish Singh <asi...@cloudera.com> > > wrote: > > > > > >> Thanks Harsha! > > >> > > >> Jun, can we add KIP-48 to next KIP hangout's agenda. Also, we did not > > >> actually make a call on when we should have next KIP call. As there > are > > a > > >> few outstanding KIPs that could not be discussed this week, can we > have > > a > > >> KIP hangout call next week? > > >> > > >> On Tue, Aug 23, 2016 at 1:10 PM, Harsha Chintalapani <ka...@harsha.io > > > > >> wrote: > > >> > > >>> Ashish, > > >>> Yes we are working on it. Lets discuss in the next KIP > meeting. > > >>> I'll join. > > >>> -Harsha > > >>> > > >>> On Tue, Aug 23, 2016 at 12:07 PM Ashish Singh <asi...@cloudera.com> > > >>> wrote: > > >>> > > >>> > Hello Harsha, > > >>> > > > >>> > Are you still working on this? Wondering if we can discuss this in > > next > > >>> KIP > > >>> > meeting, if you can join. > > >>> > > > >>> > On Mon, Jul 18, 2016 at 9:51 AM, Harsha Chintalapani < > > ka...@harsha.io> > > >>> > wrote: > > >>> > > > >>> > > Hi Grant, > > >>> > > We are working on it. Will add the details to KIP about > > the > > >>> > > request protocol. > > >>> > > > > >>> > > Thanks, > > >>> > > Harsha > > >>> > > > > >>> > > On Mon, Jul 18, 2016 at 6:50 AM Grant Henke <ghe...@cloudera.com > > > > >>> wrote: > > >>> > > > > >>> > > > Hi Parth, > > >>> > > > > > >>> > > > Are you still working on this? If you need any help please > don't > > >>> > hesitate > > >>> > > > to ask. > > >>> > > > > > >>> > > > Thanks, > > >>> > > > Grant > > >>> > > > > > >>> > > > On Thu, Jun 30, 2016 at 4:35 PM, Jun Rao <j...@confluent.io> > > wrote: > > >>> > > > > > >>> > > > > Parth, > > >>> > > > > > > >>> > > > > Thanks for the reply. > > >>> > > > > > > >>> > > > > It makes sense to only allow the renewal by users that > > >>> authenticated > > >>> > > > using > > >>> > > > > *non* delegation token mechanism. Then, should we make the > > >>> renewal a > > >>> > > > list? > > >>> > > > > For example, in the case of rest proxy, it will be useful for > > >>> every > > >>> > > > > instance of rest proxy to be able to renew the tokens. > > >>> > > > > > > >>> > > > > It would be clearer if we can document the request protocol > > like > > >>> > > > > > > >>> > > > > > > >>> > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP- > > >>> > > 4+-+Command+line+and+centralized+administrative+operations#KIP-4- > > >>> > > Commandlineandcentralizedadministrativeoperations- > > >>> > > CreateTopicsRequest(KAFKA-2945):(VotedandPlannedforin0.10.1.0) > > >>> > > > > . > > >>> > > > > > > >>> > > > > It would also be useful to document the client APIs. > > >>> > > > > > > >>> > > > > Thanks, > > >>> > > > > > > >>> > > > > Jun > > >>> > > > > > > >>> > > > > On Tue, Jun 28, 2016 at 2:55 PM, parth brahmbhatt < > > >>> > > > > brahmbhatt.pa...@gmail.com> wrote: > > >>> > > > > > > >>> > > > > > Hi, > > >>> > > > > > > > >>> > > > > > I am suggesting that we will only allow the renewal by > users > > >>> that > > >>> > > > > > authenticated using *non* delegation token mechanism. For > > >>> example, > > >>> > If > > >>> > > > > user > > >>> > > > > > Alice authenticated using kerberos and requested delegation > > >>> tokens, > > >>> > > > only > > >>> > > > > > user Alice authenticated via non delegation token mechanism > > can > > >>> > > renew. > > >>> > > > > > Clients that have access to delegation tokens can not > issue > > >>> > renewal > > >>> > > > > > request for renewing their own token and this is primarily > > >>> > important > > >>> > > to > > >>> > > > > > reduce the time window for which a compromised token will > be > > >>> valid. > > >>> > > > > > > > >>> > > > > > To clarify, Yes any authenticated user can request > delegation > > >>> > tokens > > >>> > > > but > > >>> > > > > > even here I would recommend to avoid creating a chain > where a > > >>> > client > > >>> > > > > > authenticated via delegation token request for more > > delegation > > >>> > > tokens. > > >>> > > > > > Basically anyone can request delegation token, as long as > > they > > >>> > > > > authenticate > > >>> > > > > > via a non delegation token mechanism. > > >>> > > > > > > > >>> > > > > > Aren't classes listed here > > >>> > > > > > < > > >>> > > > > > > > >>> > > > > > > >>> > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP- > > >>> > > 48+Delegation+token+support+for+Kafka#KIP-48Delegationtokens > > >>> upportforKaf > > >>> > > ka-PublicInterfaces > > >>> > > > > > > > > >>> > > > > > sufficient? > > >>> > > > > > > > >>> > > > > > Thanks > > >>> > > > > > Parth > > >>> > > > > > > > >>> > > > > > > > >>> > > > > > > > >>> > > > > > On Tue, Jun 21, 2016 at 4:33 PM, Jun Rao <j...@confluent.io > > > > >>> wrote: > > >>> > > > > > > > >>> > > > > > > Parth, > > >>> > > > > > > > > >>> > > > > > > Thanks for the reply. A couple of comments inline below. > > >>> > > > > > > > > >>> > > > > > > On Tue, Jun 21, 2016 at 10:36 AM, parth brahmbhatt < > > >>> > > > > > > brahmbhatt.pa...@gmail.com> wrote: > > >>> > > > > > > > > >>> > > > > > > > 1. Who / how are tokens renewed? By original requester > > >>> only? or > > >>> > > > using > > >>> > > > > > > > Kerberos > > >>> > > > > > > > auth only? > > >>> > > > > > > > My recommendation is to do this only using Kerberos > auth > > and > > >>> > only > > >>> > > > > threw > > >>> > > > > > > the > > >>> > > > > > > > renewer specified during the acquisition request. > > >>> > > > > > > > > > >>> > > > > > > > > > >>> > > > > > > Hmm, not sure that I follow this. Are you saying that any > > >>> client > > >>> > > > > > > authenticated with the delegation token can renew, i.e. > > there > > >>> is > > >>> > no > > >>> > > > > > renewer > > >>> > > > > > > needed? > > >>> > > > > > > > > >>> > > > > > > Also, just to be clear, any authenticated client (either > > >>> through > > >>> > > SASL > > >>> > > > > or > > >>> > > > > > > SSL) can request a delegation token for the authenticated > > >>> user, > > >>> > > > right? > > >>> > > > > > > > > >>> > > > > > > > > >>> > > > > > > > 2. Are tokens stored on each broker or in ZK? > > >>> > > > > > > > My recommendation is still to store in ZK or not store > > them > > >>> at > > >>> > > all. > > >>> > > > > The > > >>> > > > > > > > whole controller based distribution is too much > overhead > > >>> with > > >>> > not > > >>> > > > > much > > >>> > > > > > to > > >>> > > > > > > > achieve. > > >>> > > > > > > > > > >>> > > > > > > > 3. How are tokens invalidated / expired? > > >>> > > > > > > > Either by expiration time out or through an explicit > > >>> request to > > >>> > > > > > > invalidate. > > >>> > > > > > > > > > >>> > > > > > > > 4. Which encryption algorithm is used? > > >>> > > > > > > > SCRAM > > >>> > > > > > > > > > >>> > > > > > > > 5. What is the impersonation proposal (it wasn't in the > > KIP > > >>> but > > >>> > > was > > >>> > > > > > > > discussed > > >>> > > > > > > > in this thread)? > > >>> > > > > > > > There is no imperonation proposal. I tried and > explained > > how > > >>> > its > > >>> > > a > > >>> > > > > > > > different problem and why its not really necessary to > > >>> discuss > > >>> > > that > > >>> > > > as > > >>> > > > > > > part > > >>> > > > > > > > of this KIP. This KIP will not support any > > impersonation, > > >>> it > > >>> > > will > > >>> > > > > just > > >>> > > > > > > be > > >>> > > > > > > > another way to authenticate. > > >>> > > > > > > > > > >>> > > > > > > > 6. Do we need new ACLs, if so - for what actions? > > >>> > > > > > > > We do not need new ACLs. > > >>> > > > > > > > > > >>> > > > > > > > > > >>> > > > > > > Could we document the format of the new request/response > > and > > >>> > their > > >>> > > > > > > associated Resource and Operation for ACL? > > >>> > > > > > > > > >>> > > > > > > > > >>> > > > > > > > 7. How would the delegation token be configured in the > > >>> client? > > >>> > > > > > > > Should be through config. I wasn't planning on > supporting > > >>> JAAS > > >>> > > for > > >>> > > > > > > tokens. > > >>> > > > > > > > I don't believe hadoop does this either. > > >>> > > > > > > > > > >>> > > > > > > > Thanks > > >>> > > > > > > > Parth > > >>> > > > > > > > > > >>> > > > > > > > > > >>> > > > > > > > > > >>> > > > > > > > On Thu, Jun 16, 2016 at 4:03 PM, Jun Rao < > > j...@confluent.io> > > >>> > > wrote: > > >>> > > > > > > > > > >>> > > > > > > > > Harsha, > > >>> > > > > > > > > > > >>> > > > > > > > > Another question. > > >>> > > > > > > > > > > >>> > > > > > > > > 9. How would the delegation token be configured in > the > > >>> > client? > > >>> > > > The > > >>> > > > > > > > standard > > >>> > > > > > > > > way is to do this through JAAS. However, we will need > > to > > >>> > think > > >>> > > > > > through > > >>> > > > > > > if > > >>> > > > > > > > > this is convenient in a shared environment. For > > example, > > >>> > when a > > >>> > > > new > > >>> > > > > > > task > > >>> > > > > > > > is > > >>> > > > > > > > > added to a Storm worker node, do we need to > dynamically > > >>> add a > > >>> > > new > > >>> > > > > > > section > > >>> > > > > > > > > in the JAAS file? It may be more convenient if we can > > >>> pass in > > >>> > > the > > >>> > > > > > token > > >>> > > > > > > > > through the config directly w/o going through JAAS. > > >>> > > > > > > > > > > >>> > > > > > > > > Are you or Parth still actively working on this KIP? > > >>> > > > > > > > > > > >>> > > > > > > > > Thanks, > > >>> > > > > > > > > > > >>> > > > > > > > > Jun > > >>> > > > > > > > > > > >>> > > > > > > > > > > >>> > > > > > > > > > > >>> > > > > > > > > On Sun, Jun 12, 2016 at 2:18 PM, Jun Rao < > > >>> j...@confluent.io> > > >>> > > > wrote: > > >>> > > > > > > > > > > >>> > > > > > > > > > Just to add on that list. > > >>> > > > > > > > > > > > >>> > > > > > > > > > 2. It would be good to document the format of the > > data > > >>> > stored > > >>> > > > in > > >>> > > > > > ZK. > > >>> > > > > > > > > > 7. Earlier, there was a discussion on whether the > > tokens > > >>> > > should > > >>> > > > > be > > >>> > > > > > > > > > propagated through ZK like config/acl/quota, or > > through > > >>> the > > >>> > > > > > > controller. > > >>> > > > > > > > > > Currently, the controller is only designed for > > >>> propagating > > >>> > > > topic > > >>> > > > > > > > > metadata, > > >>> > > > > > > > > > but not other data. > > >>> > > > > > > > > > 8. Should we use SCRAM to send the token instead of > > >>> > > DIGEST-MD5 > > >>> > > > > > since > > >>> > > > > > > > it's > > >>> > > > > > > > > > deprecated? > > >>> > > > > > > > > > > > >>> > > > > > > > > > Also, the images in the wiki seem broken. > > >>> > > > > > > > > > > > >>> > > > > > > > > > Thanks, > > >>> > > > > > > > > > > > >>> > > > > > > > > > Jun > > >>> > > > > > > > > > > > >>> > > > > > > > > > On Fri, Jun 10, 2016 at 10:02 AM, Gwen Shapira < > > >>> > > > > g...@confluent.io> > > >>> > > > > > > > > wrote: > > >>> > > > > > > > > > > > >>> > > > > > > > > >> From what I can see, remaining questions are: > > >>> > > > > > > > > >> > > >>> > > > > > > > > >> 1. Who / how are tokens renewed? By original > > requester > > >>> > only? > > >>> > > > or > > >>> > > > > > > using > > >>> > > > > > > > > >> Kerberos auth only? > > >>> > > > > > > > > >> 2. Are tokens stored on each broker or in ZK? > > >>> > > > > > > > > >> 3. How are tokens invalidated / expired? > > >>> > > > > > > > > >> 4. Which encryption algorithm is used? > > >>> > > > > > > > > >> 5. What is the impersonation proposal (it wasn't > in > > the > > >>> > KIP > > >>> > > > but > > >>> > > > > > was > > >>> > > > > > > > > >> discussed in this thread)? > > >>> > > > > > > > > >> 6. Do we need new ACLs, if so - for what actions? > > >>> > > > > > > > > >> > > >>> > > > > > > > > >> Gwen > > >>> > > > > > > > > >> > > >>> > > > > > > > > >> On Thu, Jun 9, 2016 at 7:48 PM, Harsha < > > >>> ka...@harsha.io> > > >>> > > > wrote: > > >>> > > > > > > > > >> > Jun & Ismael, > > >>> > > > > > > > > >> > Unfortunately I > couldn't > > >>> attend > > >>> > > the > > >>> > > > > KIP > > >>> > > > > > > > > meeting > > >>> > > > > > > > > >> > when delegation tokens > > >>> > discussed. > > >>> > > > > > > > Appreciate > > >>> > > > > > > > > if > > >>> > > > > > > > > >> > you can update the > > thread if > > >>> > you > > >>> > > > have > > >>> > > > > > any > > >>> > > > > > > > > >> > further questions. > > >>> > > > > > > > > >> > Thanks, > > >>> > > > > > > > > >> > Harsha > > >>> > > > > > > > > >> > > > >>> > > > > > > > > >> > On Tue, May 24, 2016, at 11:32 AM, Liquan Pei > > wrote: > > >>> > > > > > > > > >> >> It seems that the links to images in the KIP > are > > >>> > broken. > > >>> > > > > > > > > >> >> > > >>> > > > > > > > > >> >> Liquan > > >>> > > > > > > > > >> >> > > >>> > > > > > > > > >> >> On Tue, May 24, 2016 at 9:33 AM, parth > > brahmbhatt < > > >>> > > > > > > > > >> >> brahmbhatt.pa...@gmail.com> wrote: > > >>> > > > > > > > > >> >> > > >>> > > > > > > > > >> >> > 110. What does getDelegationTokenAs mean? > > >>> > > > > > > > > >> >> > In the current proposal we only allow a user > to > > >>> get > > >>> > > > > > delegation > > >>> > > > > > > > > token > > >>> > > > > > > > > >> for > > >>> > > > > > > > > >> >> > the identity that it authenticated as using > > >>> another > > >>> > > > > > mechanism, > > >>> > > > > > > > i.e. > > >>> > > > > > > > > >> A user > > >>> > > > > > > > > >> >> > that authenticate using a keytab for > principal > > >>> > > > > > > us...@example.com > > >>> > > > > > > > > >> will get > > >>> > > > > > > > > >> >> > delegation tokens for that user only. In > > future I > > >>> > think > > >>> > > > we > > >>> > > > > > will > > >>> > > > > > > > > have > > >>> > > > > > > > > >> to > > >>> > > > > > > > > >> >> > extend support such that we allow some set of > > >>> users ( > > >>> > > > > > > > > >> >> > kafka-rest-u...@example.com, > > >>> > storm-nim...@example.com) > > >>> > > > to > > >>> > > > > > > > acquire > > >>> > > > > > > > > >> >> > delegation tokens on behalf of other users > > whose > > >>> > > identity > > >>> > > > > > they > > >>> > > > > > > > have > > >>> > > > > > > > > >> >> > verified independently. Kafka brokers will > > have > > >>> ACLs > > >>> > > to > > >>> > > > > > > control > > >>> > > > > > > > > >> which > > >>> > > > > > > > > >> >> > users are allowed to impersonate other users > > and > > >>> get > > >>> > > > tokens > > >>> > > > > > on > > >>> > > > > > > > > >> behalf of > > >>> > > > > > > > > >> >> > them. Overall Impersonation is a whole > > different > > >>> > > problem > > >>> > > > in > > >>> > > > > > my > > >>> > > > > > > > > >> opinion and > > >>> > > > > > > > > >> >> > I think we can tackle it in separate KIP. > > >>> > > > > > > > > >> >> > > > >>> > > > > > > > > >> >> > 111. What's the typical rate of getting and > > >>> renewing > > >>> > > > > > delegation > > >>> > > > > > > > > >> tokens? > > >>> > > > > > > > > >> >> > Typically this should be very very low, 1 > > request > > >>> per > > >>> > > > > minute > > >>> > > > > > > is a > > >>> > > > > > > > > >> >> > relatively high estimate. However it depends > on > > >>> the > > >>> > > token > > >>> > > > > > > > > >> expiration. I am > > >>> > > > > > > > > >> >> > less worried about the extra load it puts on > > >>> > controller > > >>> > > > vs > > >>> > > > > > the > > >>> > > > > > > > > added > > >>> > > > > > > > > >> >> > complexity and the value it offers. > > >>> > > > > > > > > >> >> > > > >>> > > > > > > > > >> >> > Thanks > > >>> > > > > > > > > >> >> > Parth > > >>> > > > > > > > > >> >> > > > >>> > > > > > > > > >> >> > > > >>> > > > > > > > > >> >> > > > >>> > > > > > > > > >> >> > On Tue, May 24, 2016 at 7:30 AM, Ismael Juma > < > > >>> > > > > > > ism...@juma.me.uk> > > >>> > > > > > > > > >> wrote: > > >>> > > > > > > > > >> >> > > > >>> > > > > > > > > >> >> > > Thanks Rajini. It would probably require a > > >>> separate > > >>> > > KIP > > >>> > > > > as > > >>> > > > > > it > > >>> > > > > > > > > will > > >>> > > > > > > > > >> >> > > introduce user visible changes. We could > also > > >>> > update > > >>> > > > > KIP-48 > > >>> > > > > > > to > > >>> > > > > > > > > >> have this > > >>> > > > > > > > > >> >> > > information, but it seems cleaner to do it > > >>> > > separately. > > >>> > > > We > > >>> > > > > > can > > >>> > > > > > > > > >> discuss > > >>> > > > > > > > > >> >> > that > > >>> > > > > > > > > >> >> > > in the KIP call today. > > >>> > > > > > > > > >> >> > > > > >>> > > > > > > > > >> >> > > Ismael > > >>> > > > > > > > > >> >> > > > > >>> > > > > > > > > >> >> > > On Tue, May 24, 2016 at 3:19 PM, Rajini > > Sivaram > > >>> < > > >>> > > > > > > > > >> >> > > rajinisiva...@googlemail.com> wrote: > > >>> > > > > > > > > >> >> > > > > >>> > > > > > > > > >> >> > > > Ismael, > > >>> > > > > > > > > >> >> > > > > > >>> > > > > > > > > >> >> > > > I have created a JIRA ( > > >>> > > > > > > > > >> >> > https://issues.apache.org/ > > jira/browse/KAFKA-3751) > > >>> > > > > > > > > >> >> > > > for adding SCRAM as a SASL mechanism. > Would > > >>> that > > >>> > > need > > >>> > > > > > > another > > >>> > > > > > > > > >> KIP? If > > >>> > > > > > > > > >> >> > > > KIP-48 will use this mechanism, can this > > just > > >>> be > > >>> > a > > >>> > > > JIRA > > >>> > > > > > > that > > >>> > > > > > > > > gets > > >>> > > > > > > > > >> >> > > reviewed > > >>> > > > > > > > > >> >> > > > when the PR is ready? > > >>> > > > > > > > > >> >> > > > > > >>> > > > > > > > > >> >> > > > Thank you, > > >>> > > > > > > > > >> >> > > > > > >>> > > > > > > > > >> >> > > > Rajini > > >>> > > > > > > > > >> >> > > > > > >>> > > > > > > > > >> >> > > > On Tue, May 24, 2016 at 2:46 PM, Ismael > > Juma < > > >>> > > > > > > > > ism...@juma.me.uk> > > >>> > > > > > > > > >> >> > wrote: > > >>> > > > > > > > > >> >> > > > > > >>> > > > > > > > > >> >> > > > > Thanks Rajini, SCRAM seems like a good > > >>> > candidate. > > >>> > > > > > > > > >> >> > > > > > > >>> > > > > > > > > >> >> > > > > Gwen had independently mentioned this > as > > a > > >>> SASL > > >>> > > > > > mechanism > > >>> > > > > > > > > that > > >>> > > > > > > > > >> might > > >>> > > > > > > > > >> >> > be > > >>> > > > > > > > > >> >> > > > > useful for Kafka and I have been > meaning > > to > > >>> > check > > >>> > > > it > > >>> > > > > in > > >>> > > > > > > > more > > >>> > > > > > > > > >> detail. > > >>> > > > > > > > > >> >> > > Good > > >>> > > > > > > > > >> >> > > > > to know that you are willing to > > contribute > > >>> an > > >>> > > > > > > > implementation. > > >>> > > > > > > > > >> Maybe > > >>> > > > > > > > > >> >> > we > > >>> > > > > > > > > >> >> > > > > should file a separate JIRA for this? > > >>> > > > > > > > > >> >> > > > > > > >>> > > > > > > > > >> >> > > > > Ismael > > >>> > > > > > > > > >> >> > > > > > > >>> > > > > > > > > >> >> > > > > On Tue, May 24, 2016 at 2:12 PM, Rajini > > >>> > Sivaram < > > >>> > > > > > > > > >> >> > > > > rajinisiva...@googlemail.com> wrote: > > >>> > > > > > > > > >> >> > > > > > > >>> > > > > > > > > >> >> > > > > > SCRAM (Salted Challenge Response > > >>> > Authentication > > >>> > > > > > > > Mechanism) > > >>> > > > > > > > > >> is a > > >>> > > > > > > > > >> >> > > better > > >>> > > > > > > > > >> >> > > > > > mechanism than Digest-MD5. Java > doesn't > > >>> come > > >>> > > > with a > > >>> > > > > > > > > built-in > > >>> > > > > > > > > >> SCRAM > > >>> > > > > > > > > >> >> > > > > > SaslServer or SaslClient, but I will > be > > >>> happy > > >>> > > to > > >>> > > > > add > > >>> > > > > > > > > support > > >>> > > > > > > > > >> in > > >>> > > > > > > > > >> >> > Kafka > > >>> > > > > > > > > >> >> > > > > since > > >>> > > > > > > > > >> >> > > > > > it would be a useful mechanism to > > support > > >>> > > anyway. > > >>> > > > > > > > > >> >> > > > > > https://tools.ietf.org/html/rfc7677 > > >>> > describes > > >>> > > > the > > >>> > > > > > > > protocol > > >>> > > > > > > > > >> for > > >>> > > > > > > > > >> >> > > > > > SCRAM-SHA-256. > > >>> > > > > > > > > >> >> > > > > > > > >>> > > > > > > > > >> >> > > > > > On Tue, May 24, 2016 at 2:37 AM, Jun > > Rao < > > >>> > > > > > > > j...@confluent.io > > >>> > > > > > > > > > > > >>> > > > > > > > > >> wrote: > > >>> > > > > > > > > >> >> > > > > > > > >>> > > > > > > > > >> >> > > > > > > Parth, > > >>> > > > > > > > > >> >> > > > > > > > > >>> > > > > > > > > >> >> > > > > > > Thanks for the explanation. A > couple > > of > > >>> > more > > >>> > > > > > > questions. > > >>> > > > > > > > > >> >> > > > > > > > > >>> > > > > > > > > >> >> > > > > > > 110. What does getDelegationTokenAs > > >>> mean? > > >>> > > > > > > > > >> >> > > > > > > > > >>> > > > > > > > > >> >> > > > > > > 111. What's the typical rate of > > getting > > >>> and > > >>> > > > > > renewing > > >>> > > > > > > > > >> delegation > > >>> > > > > > > > > >> >> > > > tokens? > > >>> > > > > > > > > >> >> > > > > > > That may have an impact on whether > > they > > >>> > > should > > >>> > > > be > > >>> > > > > > > > > directed > > >>> > > > > > > > > >> to the > > >>> > > > > > > > > >> >> > > > > > > controller. > > >>> > > > > > > > > >> >> > > > > > > > > >>> > > > > > > > > >> >> > > > > > > Jun > > >>> > > > > > > > > >> >> > > > > > > > > >>> > > > > > > > > >> >> > > > > > > On Mon, May 23, 2016 at 1:19 PM, > > parth > > >>> > > > > brahmbhatt < > > >>> > > > > > > > > >> >> > > > > > > brahmbhatt.pa...@gmail.com> wrote: > > >>> > > > > > > > > >> >> > > > > > > > > >>> > > > > > > > > >> >> > > > > > > > Hi Jun, > > >>> > > > > > > > > >> >> > > > > > > > > > >>> > > > > > > > > >> >> > > > > > > > Thanks for reviewing. > > >>> > > > > > > > > >> >> > > > > > > > > > >>> > > > > > > > > >> >> > > > > > > > * We could add a Cluster action > to > > add > > >>> > acls > > >>> > > > on > > >>> > > > > > who > > >>> > > > > > > > can > > >>> > > > > > > > > >> request > > >>> > > > > > > > > >> >> > > > > > delegation > > >>> > > > > > > > > >> >> > > > > > > > tokens. I don't see the use case > > for > > >>> that > > >>> > > yet > > >>> > > > > but > > >>> > > > > > > > down > > >>> > > > > > > > > >> the line > > >>> > > > > > > > > >> >> > > > when > > >>> > > > > > > > > >> >> > > > > we > > >>> > > > > > > > > >> >> > > > > > > > start supporting > > getDelegationTokenAs > > >>> it > > >>> > > will > > >>> > > > > be > > >>> > > > > > > > > >> necessary. > > >>> > > > > > > > > >> >> > > > > > > > * Yes we recommend tokens to be > > only > > >>> > > > > > > used/distributed > > >>> > > > > > > > > >> over > > >>> > > > > > > > > >> >> > secure > > >>> > > > > > > > > >> >> > > > > > > channels. > > >>> > > > > > > > > >> >> > > > > > > > * Depending on what design we end > > up > > >>> > > choosing > > >>> > > > > > > > > >> Invalidation will > > >>> > > > > > > > > >> >> > > be > > >>> > > > > > > > > >> >> > > > > > > > responsibility of every broker or > > >>> > > controller. > > >>> > > > > > > > > >> >> > > > > > > > * I am not sure if I documented > > >>> somewhere > > >>> > > > that > > >>> > > > > > > > > >> invalidation > > >>> > > > > > > > > >> >> > will > > >>> > > > > > > > > >> >> > > > > > directly > > >>> > > > > > > > > >> >> > > > > > > > go through zookeeper but that is > > not > > >>> the > > >>> > > > > intent. > > >>> > > > > > > > > >> Invalidation > > >>> > > > > > > > > >> >> > > will > > >>> > > > > > > > > >> >> > > > > > either > > >>> > > > > > > > > >> >> > > > > > > > be request based or due to > > >>> expiration. No > > >>> > > > > direct > > >>> > > > > > > > > >> zookeeper > > >>> > > > > > > > > >> >> > > > > interaction > > >>> > > > > > > > > >> >> > > > > > > from > > >>> > > > > > > > > >> >> > > > > > > > any client. > > >>> > > > > > > > > >> >> > > > > > > > * "Broker also stores the > > >>> DelegationToken > > >>> > > > > without > > >>> > > > > > > the > > >>> > > > > > > > > >> hmac in > > >>> > > > > > > > > >> >> > the > > >>> > > > > > > > > >> >> > > > > > > > zookeeper." : Sorry about the > > >>> confusion. > > >>> > > The > > >>> > > > > sole > > >>> > > > > > > > > >> purpose of > > >>> > > > > > > > > >> >> > > > > zookeeper > > >>> > > > > > > > > >> >> > > > > > in > > >>> > > > > > > > > >> >> > > > > > > > this design is as distribution > > channel > > >>> > for > > >>> > > > > tokens > > >>> > > > > > > > > >> between all > > >>> > > > > > > > > >> >> > > > brokers > > >>> > > > > > > > > >> >> > > > > > > and a > > >>> > > > > > > > > >> >> > > > > > > > layer that ensures only tokens > that > > >>> were > > >>> > > > > > generated > > >>> > > > > > > by > > >>> > > > > > > > > >> making a > > >>> > > > > > > > > >> >> > > > > request > > >>> > > > > > > > > >> >> > > > > > > to a > > >>> > > > > > > > > >> >> > > > > > > > broker will be accepted (more on > > this > > >>> in > > >>> > > > second > > >>> > > > > > > > > >> paragraph). The > > >>> > > > > > > > > >> >> > > > token > > >>> > > > > > > > > >> >> > > > > > > > consists of few elements (owner, > > >>> renewer, > > >>> > > > uuid > > >>> > > > > , > > >>> > > > > > > > > >> expiration, > > >>> > > > > > > > > >> >> > > hmac) > > >>> > > > > > > > > >> >> > > > , > > >>> > > > > > > > > >> >> > > > > > one > > >>> > > > > > > > > >> >> > > > > > > of > > >>> > > > > > > > > >> >> > > > > > > > which is the finally generated > hmac > > >>> but > > >>> > > hmac > > >>> > > > it > > >>> > > > > > > self > > >>> > > > > > > > is > > >>> > > > > > > > > >> >> > derivable > > >>> > > > > > > > > >> >> > > > if > > >>> > > > > > > > > >> >> > > > > > you > > >>> > > > > > > > > >> >> > > > > > > > have all the other elements of > the > > >>> token > > >>> > + > > >>> > > > > secret > > >>> > > > > > > key > > >>> > > > > > > > > to > > >>> > > > > > > > > >> >> > generate > > >>> > > > > > > > > >> >> > > > > hmac. > > >>> > > > > > > > > >> >> > > > > > > > Given zookeeper does not provide > > SSL > > >>> > > support > > >>> > > > we > > >>> > > > > > do > > >>> > > > > > > > not > > >>> > > > > > > > > >> want the > > >>> > > > > > > > > >> >> > > > > entire > > >>> > > > > > > > > >> >> > > > > > > > token to be wire transferred to > > >>> zookeeper > > >>> > > as > > >>> > > > > that > > >>> > > > > > > > will > > >>> > > > > > > > > >> be an > > >>> > > > > > > > > >> >> > > > insecure > > >>> > > > > > > > > >> >> > > > > > > wire > > >>> > > > > > > > > >> >> > > > > > > > transfer. Instead we only store > all > > >>> the > > >>> > > other > > >>> > > > > > > > elements > > >>> > > > > > > > > >> of a > > >>> > > > > > > > > >> >> > > > > delegation > > >>> > > > > > > > > >> >> > > > > > > > tokens. Brokers can read these > > >>> elements > > >>> > and > > >>> > > > > > because > > >>> > > > > > > > > they > > >>> > > > > > > > > >> also > > >>> > > > > > > > > >> >> > > have > > >>> > > > > > > > > >> >> > > > > > access > > >>> > > > > > > > > >> >> > > > > > > > to secret key they will be able > to > > >>> > generate > > >>> > > > > hmac > > >>> > > > > > on > > >>> > > > > > > > > >> their end. > > >>> > > > > > > > > >> >> > > > > > > > > > >>> > > > > > > > > >> >> > > > > > > > One of the alternative proposed > is > > to > > >>> > avoid > > >>> > > > > > > zookeeper > > >>> > > > > > > > > >> >> > > altogether. A > > >>> > > > > > > > > >> >> > > > > > > Client > > >>> > > > > > > > > >> >> > > > > > > > will call broker with required > > >>> > information > > >>> > > > > > (owner, > > >>> > > > > > > > > >> renwer, > > >>> > > > > > > > > >> >> > > > > expiration) > > >>> > > > > > > > > >> >> > > > > > > and > > >>> > > > > > > > > >> >> > > > > > > > get back (signed hmac, uuid). > > Broker > > >>> > won't > > >>> > > > > store > > >>> > > > > > > this > > >>> > > > > > > > > in > > >>> > > > > > > > > >> >> > > zookeeper. > > >>> > > > > > > > > >> >> > > > > > From > > >>> > > > > > > > > >> >> > > > > > > > this point a client can contact > any > > >>> > broker > > >>> > > > with > > >>> > > > > > all > > >>> > > > > > > > the > > >>> > > > > > > > > >> >> > > delegation > > >>> > > > > > > > > >> >> > > > > > token > > >>> > > > > > > > > >> >> > > > > > > > info (owner, rewner, expiration, > > hmac, > > >>> > > uuid) > > >>> > > > > the > > >>> > > > > > > > borker > > >>> > > > > > > > > >> will > > >>> > > > > > > > > >> >> > > > > regenerate > > >>> > > > > > > > > >> >> > > > > > > the > > >>> > > > > > > > > >> >> > > > > > > > hmac and as long as it matches > with > > >>> hmac > > >>> > > > > > presented > > >>> > > > > > > by > > >>> > > > > > > > > >> client , > > >>> > > > > > > > > >> >> > > > broker > > >>> > > > > > > > > >> >> > > > > > > will > > >>> > > > > > > > > >> >> > > > > > > > allow the request to > authenticate. > > >>> Only > > >>> > > > > problem > > >>> > > > > > > with > > >>> > > > > > > > > >> this > > >>> > > > > > > > > >> >> > > approach > > >>> > > > > > > > > >> >> > > > > is > > >>> > > > > > > > > >> >> > > > > > if > > >>> > > > > > > > > >> >> > > > > > > > the secret key is compromised any > > >>> client > > >>> > > can > > >>> > > > > now > > >>> > > > > > > > > generate > > >>> > > > > > > > > >> >> > random > > >>> > > > > > > > > >> >> > > > > tokens > > >>> > > > > > > > > >> >> > > > > > > and > > >>> > > > > > > > > >> >> > > > > > > > they will still be able to > > >>> authenticate > > >>> > as > > >>> > > > any > > >>> > > > > > user > > >>> > > > > > > > > they > > >>> > > > > > > > > >> like. > > >>> > > > > > > > > >> >> > > with > > >>> > > > > > > > > >> >> > > > > > > > zookeeper we guarantee that only > > >>> tokens > > >>> > > > > acquired > > >>> > > > > > > via > > >>> > > > > > > > a > > >>> > > > > > > > > >> broker > > >>> > > > > > > > > >> >> > > > (using > > >>> > > > > > > > > >> >> > > > > > some > > >>> > > > > > > > > >> >> > > > > > > > auth scheme other than delegation > > >>> token) > > >>> > > will > > >>> > > > > be > > >>> > > > > > > > > >> accepted. We > > >>> > > > > > > > > >> >> > > need > > >>> > > > > > > > > >> >> > > > to > > >>> > > > > > > > > >> >> > > > > > > > discuss which proposal makes more > > >>> sense > > >>> > and > > >>> > > > we > > >>> > > > > > can > > >>> > > > > > > go > > >>> > > > > > > > > >> over it > > >>> > > > > > > > > >> >> > in > > >>> > > > > > > > > >> >> > > > > > > tomorrow's > > >>> > > > > > > > > >> >> > > > > > > > meeting. > > >>> > > > > > > > > >> >> > > > > > > > > > >>> > > > > > > > > >> >> > > > > > > > Also, can you forward the invite > to > > >>> me? > > >>> > > > > > > > > >> >> > > > > > > > > > >>> > > > > > > > > >> >> > > > > > > > Thanks > > >>> > > > > > > > > >> >> > > > > > > > Parth > > >>> > > > > > > > > >> >> > > > > > > > > > >>> > > > > > > > > >> >> > > > > > > > > > >>> > > > > > > > > >> >> > > > > > > > > > >>> > > > > > > > > >> >> > > > > > > > On Mon, May 23, 2016 at 10:35 AM, > > Jun > > >>> > Rao < > > >>> > > > > > > > > >> j...@confluent.io> > > >>> > > > > > > > > >> >> > > > wrote: > > >>> > > > > > > > > >> >> > > > > > > > > > >>> > > > > > > > > >> >> > > > > > > > > Thanks for the KIP. A few > > comments. > > >>> > > > > > > > > >> >> > > > > > > > > > > >>> > > > > > > > > >> >> > > > > > > > > 100. This potentially can be > > useful > > >>> for > > >>> > > > Kafka > > >>> > > > > > > > Connect > > >>> > > > > > > > > >> and > > >>> > > > > > > > > >> >> > Kafka > > >>> > > > > > > > > >> >> > > > > rest > > >>> > > > > > > > > >> >> > > > > > > > proxy > > >>> > > > > > > > > >> >> > > > > > > > > where a worker agent will need > to > > >>> run a > > >>> > > > task > > >>> > > > > on > > >>> > > > > > > > > behalf > > >>> > > > > > > > > >> of a > > >>> > > > > > > > > >> >> > > > client. > > >>> > > > > > > > > >> >> > > > > > We > > >>> > > > > > > > > >> >> > > > > > > > will > > >>> > > > > > > > > >> >> > > > > > > > > likely need to change how those > > >>> > services > > >>> > > > use > > >>> > > > > > > Kafka > > >>> > > > > > > > > >> clients > > >>> > > > > > > > > >> >> > > > > > > > > (producer/consumer). Instead > of a > > >>> > shared > > >>> > > > > client > > >>> > > > > > > per > > >>> > > > > > > > > >> worker, > > >>> > > > > > > > > >> >> > we > > >>> > > > > > > > > >> >> > > > will > > >>> > > > > > > > > >> >> > > > > > > need > > >>> > > > > > > > > >> >> > > > > > > > a > > >>> > > > > > > > > >> >> > > > > > > > > client per user task since the > > >>> > > > authentication > > >>> > > > > > > > happens > > >>> > > > > > > > > >> at the > > >>> > > > > > > > > >> >> > > > > > connection > > >>> > > > > > > > > >> >> > > > > > > > > level. For Kafka Connect, the > > >>> renewer > > >>> > > will > > >>> > > > be > > >>> > > > > > the > > >>> > > > > > > > > >> workers. > > >>> > > > > > > > > >> >> > So, > > >>> > > > > > > > > >> >> > > we > > >>> > > > > > > > > >> >> > > > > > > > probably > > >>> > > > > > > > > >> >> > > > > > > > > need to allow multiple > renewers. > > For > > >>> > > Kafka > > >>> > > > > rest > > >>> > > > > > > > > proxy, > > >>> > > > > > > > > >> the > > >>> > > > > > > > > >> >> > > > renewer > > >>> > > > > > > > > >> >> > > > > > can > > >>> > > > > > > > > >> >> > > > > > > > > probably just be the creator of > > the > > >>> > > token. > > >>> > > > > > > > > >> >> > > > > > > > > > > >>> > > > > > > > > >> >> > > > > > > > > 101. Do we need new acl on who > > can > > >>> > > request > > >>> > > > > > > > delegation > > >>> > > > > > > > > >> tokens? > > >>> > > > > > > > > >> >> > > > > > > > > > > >>> > > > > > > > > >> >> > > > > > > > > 102. Do we recommend people to > > send > > >>> > > > > delegation > > >>> > > > > > > > tokens > > >>> > > > > > > > > >> in an > > >>> > > > > > > > > >> >> > > > > encrypted > > >>> > > > > > > > > >> >> > > > > > > > > channel? > > >>> > > > > > > > > >> >> > > > > > > > > > > >>> > > > > > > > > >> >> > > > > > > > > 103. Who is responsible for > > expiring > > >>> > > > tokens, > > >>> > > > > > > every > > >>> > > > > > > > > >> broker? > > >>> > > > > > > > > >> >> > > > > > > > > > > >>> > > > > > > > > >> >> > > > > > > > > 104. For invalidating tokens, > > would > > >>> it > > >>> > be > > >>> > > > > > better > > >>> > > > > > > to > > >>> > > > > > > > > do > > >>> > > > > > > > > >> it in > > >>> > > > > > > > > >> >> > a > > >>> > > > > > > > > >> >> > > > > > request > > >>> > > > > > > > > >> >> > > > > > > > > instead of going to ZK > directly? > > >>> > > > > > > > > >> >> > > > > > > > > > > >>> > > > > > > > > >> >> > > > > > > > > 105. The terminology of client > in > > >>> the > > >>> > > wiki > > >>> > > > > > > > sometimes > > >>> > > > > > > > > >> refers > > >>> > > > > > > > > >> >> > to > > >>> > > > > > > > > >> >> > > > the > > >>> > > > > > > > > >> >> > > > > > end > > >>> > > > > > > > > >> >> > > > > > > > > client and some other times > > refers > > >>> to > > >>> > the > > >>> > > > > > client > > >>> > > > > > > > > using > > >>> > > > > > > > > >> the > > >>> > > > > > > > > >> >> > > > > delegation > > >>> > > > > > > > > >> >> > > > > > > > > tokens. It would be useful to > > >>> > distinguish > > >>> > > > > > between > > >>> > > > > > > > the > > >>> > > > > > > > > >> two. > > >>> > > > > > > > > >> >> > > > > > > > > > > >>> > > > > > > > > >> >> > > > > > > > > 106. Could you explain the > > sentence > > >>> > > "Broker > > >>> > > > > > also > > >>> > > > > > > > > >> stores the > > >>> > > > > > > > > >> >> > > > > > > > DelegationToken > > >>> > > > > > > > > >> >> > > > > > > > > without the hmac in the > > zookeeper." > > >>> a > > >>> > bit > > >>> > > > > > more? I > > >>> > > > > > > > > >> thought the > > >>> > > > > > > > > >> >> > > > > > > delegation > > >>> > > > > > > > > >> >> > > > > > > > > token is the hmac. > > >>> > > > > > > > > >> >> > > > > > > > > > > >>> > > > > > > > > >> >> > > > > > > > > Thanks, > > >>> > > > > > > > > >> >> > > > > > > > > > > >>> > > > > > > > > >> >> > > > > > > > > Jun > > >>> > > > > > > > > >> >> > > > > > > > > > > >>> > > > > > > > > >> >> > > > > > > > > > > >>> > > > > > > > > >> >> > > > > > > > > On Mon, May 23, 2016 at 9:22 > AM, > > Jun > > >>> > Rao > > >>> > > < > > >>> > > > > > > > > >> j...@confluent.io> > > >>> > > > > > > > > >> >> > > > wrote: > > >>> > > > > > > > > >> >> > > > > > > > > > > >>> > > > > > > > > >> >> > > > > > > > > > Hi, Harsha, > > >>> > > > > > > > > >> >> > > > > > > > > > > > >>> > > > > > > > > >> >> > > > > > > > > > Just sent out a KIP meeting > > >>> invite. > > >>> > We > > >>> > > > can > > >>> > > > > > > > discuss > > >>> > > > > > > > > >> this in > > >>> > > > > > > > > >> >> > > the > > >>> > > > > > > > > >> >> > > > > > > meeting > > >>> > > > > > > > > >> >> > > > > > > > > > tomorrow. > > >>> > > > > > > > > >> >> > > > > > > > > > > > >>> > > > > > > > > >> >> > > > > > > > > > Thanks, > > >>> > > > > > > > > >> >> > > > > > > > > > > > >>> > > > > > > > > >> >> > > > > > > > > > Jun > > >>> > > > > > > > > >> >> > > > > > > > > > > > >>> > > > > > > > > >> >> > > > > > > > > > On Thu, May 19, 2016 at 8:47 > > AM, > > >>> > > Harsha < > > >>> > > > > > > > > >> ka...@harsha.io> > > >>> > > > > > > > > >> >> > > > wrote: > > >>> > > > > > > > > >> >> > > > > > > > > > > > >>> > > > > > > > > >> >> > > > > > > > > >> Hi All, > > >>> > > > > > > > > >> >> > > > > > > > > >> Can we have a KIP > > >>> meeting > > >>> > > > > around > > >>> > > > > > > > this. > > >>> > > > > > > > > >> The KIP > > >>> > > > > > > > > >> >> > is > > >>> > > > > > > > > >> >> > > > up > > >>> > > > > > > > > >> >> > > > > > for > > >>> > > > > > > > > >> >> > > > > > > > > >> sometime and if > > there > > >>> are > > >>> > > any > > >>> > > > > > > > questions > > >>> > > > > > > > > >> lets > > >>> > > > > > > > > >> >> > > > quickly > > >>> > > > > > > > > >> >> > > > > > hash > > >>> > > > > > > > > >> >> > > > > > > > out > > >>> > > > > > > > > >> >> > > > > > > > > >> details. > > >>> > > > > > > > > >> >> > > > > > > > > >> > > >>> > > > > > > > > >> >> > > > > > > > > >> Thanks, > > >>> > > > > > > > > >> >> > > > > > > > > >> Harsha > > >>> > > > > > > > > >> >> > > > > > > > > >> > > >>> > > > > > > > > >> >> > > > > > > > > >> On Thu, May 19, 2016, at > 08:40 > > >>> AM, > > >>> > > parth > > >>> > > > > > > > > brahmbhatt > > >>> > > > > > > > > >> wrote: > > >>> > > > > > > > > >> >> > > > > > > > > >> > That is what the hadoop > echo > > >>> > system > > >>> > > > uses > > >>> > > > > > so > > >>> > > > > > > no > > >>> > > > > > > > > >> good > > >>> > > > > > > > > >> >> > reason > > >>> > > > > > > > > >> >> > > > > > really. > > >>> > > > > > > > > >> >> > > > > > > > We > > >>> > > > > > > > > >> >> > > > > > > > > >> > could > > >>> > > > > > > > > >> >> > > > > > > > > >> > change it to whatever is > the > > >>> > newest > > >>> > > > > > > > recommended > > >>> > > > > > > > > >> standard > > >>> > > > > > > > > >> >> > > is. > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > >>> > > > > > > > > >> >> > > > > > > > > >> > Thanks > > >>> > > > > > > > > >> >> > > > > > > > > >> > Parth > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > >>> > > > > > > > > >> >> > > > > > > > > >> > On Thu, May 19, 2016 at > 3:33 > > >>> AM, > > >>> > > > Ismael > > >>> > > > > > > Juma < > > >>> > > > > > > > > >> >> > > > > ism...@juma.me.uk > > >>> > > > > > > > > >> >> > > > > > > > > >>> > > > > > > > > >> >> > > > > > > > > wrote: > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > >>> > > > > > > > > >> >> > > > > > > > > >> > > Hi Parth, > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > > >>> > > > > > > > > >> >> > > > > > > > > >> > > Thanks for the KIP. I > only > > >>> > started > > >>> > > > > > > reviewing > > >>> > > > > > > > > >> this and > > >>> > > > > > > > > >> >> > > may > > >>> > > > > > > > > >> >> > > > > have > > >>> > > > > > > > > >> >> > > > > > > > > >> additional > > >>> > > > > > > > > >> >> > > > > > > > > >> > > questions later. The > > >>> immediate > > >>> > > > > question > > >>> > > > > > > that > > >>> > > > > > > > > >> came to > > >>> > > > > > > > > >> >> > > mind > > >>> > > > > > > > > >> >> > > > is > > >>> > > > > > > > > >> >> > > > > > our > > >>> > > > > > > > > >> >> > > > > > > > > >> choice of > > >>> > > > > > > > > >> >> > > > > > > > > >> > > "DIGEST-MD5" even though > > it's > > >>> > > marked > > >>> > > > > as > > >>> > > > > > > > > >> OBSOLETE in > > >>> > > > > > > > > >> >> > the > > >>> > > > > > > > > >> >> > > > IANA > > >>> > > > > > > > > >> >> > > > > > > > > Registry > > >>> > > > > > > > > >> >> > > > > > > > > >> of > > >>> > > > > > > > > >> >> > > > > > > > > >> > > SASL mechanisms and the > > >>> original > > >>> > > RFC > > >>> > > > > > > (2831) > > >>> > > > > > > > > has > > >>> > > > > > > > > >> been > > >>> > > > > > > > > >> >> > > moved > > >>> > > > > > > > > >> >> > > > > to > > >>> > > > > > > > > >> >> > > > > > > > > Historic > > >>> > > > > > > > > >> >> > > > > > > > > >> > > status: > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > > https://tools.ietf.org/html/ > > >>> > > rfc6331 > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > > >>> > > > > > > > > >> >> > > > > > > > > > > >>> > > > > > > > > >> >> > > > > > > > >>> > > > > > > > > >> >> > > > > >>> > > > > > > > > >> > > >>> > > > > > > > > >>> > > > http://www.iana.org/assignments/sasl-mechanisms/sasl- > > >>> mechanisms.xhtml > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > > >>> > > > > > > > > >> >> > > > > > > > > >> > > What is the reasoning > > behind > > >>> > that > > >>> > > > > > choice? > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > > >>> > > > > > > > > >> >> > > > > > > > > >> > > Thanks, > > >>> > > > > > > > > >> >> > > > > > > > > >> > > Ismael > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > > >>> > > > > > > > > >> >> > > > > > > > > >> > > On Fri, May 13, 2016 at > > 11:29 > > >>> > PM, > > >>> > > > Gwen > > >>> > > > > > > > > Shapira < > > >>> > > > > > > > > >> >> > > > > > > g...@confluent.io > > >>> > > > > > > > > >> >> > > > > > > > > > > >>> > > > > > > > > >> >> > > > > > > > > >> wrote: > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > Also comments inline > :) > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > > * I want to > emphasize > > >>> that > > >>> > > even > > >>> > > > > > though > > >>> > > > > > > > > >> delegation > > >>> > > > > > > > > >> >> > > > tokens > > >>> > > > > > > > > >> >> > > > > > > are a > > >>> > > > > > > > > >> >> > > > > > > > > >> Hadoop > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > > innovation, I feel > > very > > >>> > > strongly > > >>> > > > > > about > > >>> > > > > > > > not > > >>> > > > > > > > > >> adding > > >>> > > > > > > > > >> >> > > > > > dependency > > >>> > > > > > > > > >> >> > > > > > > > on > > >>> > > > > > > > > >> >> > > > > > > > > >> Hadoop > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > > when implementing > > >>> delegation > > >>> > > > > tokens > > >>> > > > > > > for > > >>> > > > > > > > > >> Kafka. The > > >>> > > > > > > > > >> >> > > KIP > > >>> > > > > > > > > >> >> > > > > > > doesn't > > >>> > > > > > > > > >> >> > > > > > > > > >> imply > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > > such dependency, but > > if > > >>> you > > >>> > > can > > >>> > > > > > > > clarify... > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > > > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > > > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > > *No hadoop > > dependency.* > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > Yay! Just add this to > > the > > >>> KIP > > >>> > so > > >>> > > > no > > >>> > > > > > one > > >>> > > > > > > > will > > >>> > > > > > > > > >> read > > >>> > > > > > > > > >> >> > the > > >>> > > > > > > > > >> >> > > > KIP > > >>> > > > > > > > > >> >> > > > > > and > > >>> > > > > > > > > >> >> > > > > > > > > panic > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > three weeks before the > > next > > >>> > > > > release... > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > > * Can we get > > delegation > > >>> > token > > >>> > > at > > >>> > > > > any > > >>> > > > > > > > time > > >>> > > > > > > > > >> after > > >>> > > > > > > > > >> >> > > > > > > > authenticating? > > >>> > > > > > > > > >> >> > > > > > > > > >> only > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > > immediately after? > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > > > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > > > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > > *As long as you are > > >>> > > > authenticated > > >>> > > > > > you > > >>> > > > > > > > can > > >>> > > > > > > > > >> get > > >>> > > > > > > > > >> >> > > > delegation > > >>> > > > > > > > > >> >> > > > > > > > tokens. > > >>> > > > > > > > > >> >> > > > > > > > > >> We > > >>> > > > > > > > > >> >> > > > > > > > > >> > > need > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > to > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > > discuss if a client > > >>> > > > authenticated > > >>> > > > > > > using > > >>> > > > > > > > > >> delegation > > >>> > > > > > > > > >> >> > > > > token, > > >>> > > > > > > > > >> >> > > > > > > can > > >>> > > > > > > > > >> >> > > > > > > > > also > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > acquire > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > > delegation token > > again or > > >>> > not. > > >>> > > > > Also > > >>> > > > > > > > there > > >>> > > > > > > > > >> is the > > >>> > > > > > > > > >> >> > > > > question > > >>> > > > > > > > > >> >> > > > > > of > > >>> > > > > > > > > >> >> > > > > > > > do > > >>> > > > > > > > > >> >> > > > > > > > > we > > >>> > > > > > > > > >> >> > > > > > > > > >> > > allow > > >>> > > > > > > > > >> >> > > > > > > > > >> > > > > anyone to acquire > > >>> delegation > > >>> > > > token > > >>> > > > > > or > > >>> > > > > > > we > > >>> > > > > > > > > >> want > > >>> > > > > > > > > >> >> > > specific > > >>> > > > > > > > > >>
