Is it updated? are all concerns addressed? do you want to start a vote? Sorry for being pushy, I do appreciate that we are all volunteers and finding time is difficult. This feature is important for anything that integrates with Kafka (stream processors, Flume, NiFi, etc) and I don't want to see this getting stuck because we lack coordination within the community.
On Thu, Sep 15, 2016 at 6:39 PM, Harsha Chintalapani <ka...@harsha.io> wrote: > 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 >> > >>> > > > > > > > > >> -- Gwen Shapira Product Manager | Confluent 650.450.2760 | @gwenshap Follow us: Twitter | blog
