Re: [VOTE] KIP-1025: Optionally URL-encode clientID and clientSecret in authorization header
Hi all, I want to bump up this thread for visibility. Currently, this KIP is one binding vote short of being accepted. Thanks! On Thu, May 16, 2024 at 1:07 AM Mickael Maison wrote: > Hi, > > +1 (binding) > Thanks for the KIP! > > Mickael > > On Sun, Apr 21, 2024 at 7:12 PM Nelson B. wrote: > > > > Hi all, > > > > Just a kind reminder. I would really appreciate if we could get two more > > binding +1 votes. > > > > Thanks > > > > On Mon, Apr 8, 2024, 2:08 PM Manikumar > wrote: > > > > > Thanks for the KIP. > > > > > > +1 (binding) > > > > > > > > > > > > > > > On Mon, Apr 8, 2024 at 9:49 AM Kirk True wrote: > > > > > > > > +1 (non-binding) > > > > > > > > Apologies. I thought I’d already voted :( > > > > > > > > > On Apr 7, 2024, at 10:48 AM, Nelson B. > > > wrote: > > > > > > > > > > Hi all, > > > > > > > > > > Just wanted to bump up this thread for visibility. > > > > > > > > > > Thanks! > > > > > > > > > > On Thu, Mar 28, 2024 at 3:40 AM Doğuşcan Namal < > > > namal.dogus...@gmail.com> > > > > > wrote: > > > > > > > > > >> Thanks for checking it out Nelson. Yeah I think it makes sense to > > > leave it > > > > >> for the users who want to use it for testing. > > > > >> > > > > >> On Mon, 25 Mar 2024 at 20:44, Nelson B. > > > wrote: > > > > >> > > > > >>> Hi Doğuşcan, > > > > >>> > > > > >>> Thanks for your vote! > > > > >>> > > > > >>> Currently, the usage of TLS depends on the protocol used by the > > > > >>> authorization server which is configured > > > > >>> through the "sasl.oauthbearer.token.endpoint.url" option. So, if > the > > > > >>> URL address uses simple http (not https) > > > > >>> then secrets will be transmitted in plaintext. I think it's > possible > > > to > > > > >>> enforce using only https but I think any > > > > >>> production-grade authorization server uses https anyway and maybe > > > users > > > > >> may > > > > >>> want to test using http in the dev environment. > > > > >>> > > > > >>> Thanks, > > > > >>> > > > > >>> On Thu, Mar 21, 2024 at 3:56 PM Doğuşcan Namal < > > > namal.dogus...@gmail.com > > > > >>> > > > > >>> wrote: > > > > >>> > > > > Hi Nelson, thanks for the KIP. > > > > > > > > From the RFC: > > > > ``` > > > > The authorization server MUST require the use of TLS as > described in > > > > Section 1.6 when sending requests using password > authentication. > > > > ``` > > > > > > > > I believe we already have an enforcement for OAuth to be enabled > > > only > > > > >> in > > > > SSLChannel but would be good to double check. Sending secrets > over > > > > plaintext is a security bad practice :) > > > > > > > > +1 (non-binding) from me. > > > > > > > > On Tue, 19 Mar 2024 at 16:00, Nelson B. < > bachmanity...@gmail.com> > > > > >> wrote: > > > > > > > > > Hi all, > > > > > > > > > > I would like to start a vote on KIP-1025 > > > > > < > > > > > > > > > > > > > >>> > > > > >> > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1025%3A+Optionally+URL-encode+clientID+and+clientSecret+in+authorization+header > > > > >> , > > > > > which would optionally URL-encode clientID and clientSecret in > the > > > > > authorization header. > > > > > > > > > > I feel like all possible issues have been addressed in the > > > discussion > > > > > thread. > > > > > > > > > > Thanks, > > > > > > > > > > > > > >>> > > > > >> > > > > > > > >
Re: [VOTE] KIP-1025: Optionally URL-encode clientID and clientSecret in authorization header
Hi, +1 (binding) Thanks for the KIP! Mickael On Sun, Apr 21, 2024 at 7:12 PM Nelson B. wrote: > > Hi all, > > Just a kind reminder. I would really appreciate if we could get two more > binding +1 votes. > > Thanks > > On Mon, Apr 8, 2024, 2:08 PM Manikumar wrote: > > > Thanks for the KIP. > > > > +1 (binding) > > > > > > > > > > On Mon, Apr 8, 2024 at 9:49 AM Kirk True wrote: > > > > > > +1 (non-binding) > > > > > > Apologies. I thought I’d already voted :( > > > > > > > On Apr 7, 2024, at 10:48 AM, Nelson B. > > wrote: > > > > > > > > Hi all, > > > > > > > > Just wanted to bump up this thread for visibility. > > > > > > > > Thanks! > > > > > > > > On Thu, Mar 28, 2024 at 3:40 AM Doğuşcan Namal < > > namal.dogus...@gmail.com> > > > > wrote: > > > > > > > >> Thanks for checking it out Nelson. Yeah I think it makes sense to > > leave it > > > >> for the users who want to use it for testing. > > > >> > > > >> On Mon, 25 Mar 2024 at 20:44, Nelson B. > > wrote: > > > >> > > > >>> Hi Doğuşcan, > > > >>> > > > >>> Thanks for your vote! > > > >>> > > > >>> Currently, the usage of TLS depends on the protocol used by the > > > >>> authorization server which is configured > > > >>> through the "sasl.oauthbearer.token.endpoint.url" option. So, if the > > > >>> URL address uses simple http (not https) > > > >>> then secrets will be transmitted in plaintext. I think it's possible > > to > > > >>> enforce using only https but I think any > > > >>> production-grade authorization server uses https anyway and maybe > > users > > > >> may > > > >>> want to test using http in the dev environment. > > > >>> > > > >>> Thanks, > > > >>> > > > >>> On Thu, Mar 21, 2024 at 3:56 PM Doğuşcan Namal < > > namal.dogus...@gmail.com > > > >>> > > > >>> wrote: > > > >>> > > > Hi Nelson, thanks for the KIP. > > > > > > From the RFC: > > > ``` > > > The authorization server MUST require the use of TLS as described in > > > Section 1.6 when sending requests using password authentication. > > > ``` > > > > > > I believe we already have an enforcement for OAuth to be enabled > > only > > > >> in > > > SSLChannel but would be good to double check. Sending secrets over > > > plaintext is a security bad practice :) > > > > > > +1 (non-binding) from me. > > > > > > On Tue, 19 Mar 2024 at 16:00, Nelson B. > > > >> wrote: > > > > > > > Hi all, > > > > > > > > I would like to start a vote on KIP-1025 > > > > < > > > > > > > > > > >>> > > > >> > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1025%3A+Optionally+URL-encode+clientID+and+clientSecret+in+authorization+header > > > >> , > > > > which would optionally URL-encode clientID and clientSecret in the > > > > authorization header. > > > > > > > > I feel like all possible issues have been addressed in the > > discussion > > > > thread. > > > > > > > > Thanks, > > > > > > > > > > >>> > > > >> > > > > >
Re: [VOTE] KIP-1025: Optionally URL-encode clientID and clientSecret in authorization header
Hi all, Just a kind reminder. I would really appreciate if we could get two more binding +1 votes. Thanks On Mon, Apr 8, 2024, 2:08 PM Manikumar wrote: > Thanks for the KIP. > > +1 (binding) > > > > > On Mon, Apr 8, 2024 at 9:49 AM Kirk True wrote: > > > > +1 (non-binding) > > > > Apologies. I thought I’d already voted :( > > > > > On Apr 7, 2024, at 10:48 AM, Nelson B. > wrote: > > > > > > Hi all, > > > > > > Just wanted to bump up this thread for visibility. > > > > > > Thanks! > > > > > > On Thu, Mar 28, 2024 at 3:40 AM Doğuşcan Namal < > namal.dogus...@gmail.com> > > > wrote: > > > > > >> Thanks for checking it out Nelson. Yeah I think it makes sense to > leave it > > >> for the users who want to use it for testing. > > >> > > >> On Mon, 25 Mar 2024 at 20:44, Nelson B. > wrote: > > >> > > >>> Hi Doğuşcan, > > >>> > > >>> Thanks for your vote! > > >>> > > >>> Currently, the usage of TLS depends on the protocol used by the > > >>> authorization server which is configured > > >>> through the "sasl.oauthbearer.token.endpoint.url" option. So, if the > > >>> URL address uses simple http (not https) > > >>> then secrets will be transmitted in plaintext. I think it's possible > to > > >>> enforce using only https but I think any > > >>> production-grade authorization server uses https anyway and maybe > users > > >> may > > >>> want to test using http in the dev environment. > > >>> > > >>> Thanks, > > >>> > > >>> On Thu, Mar 21, 2024 at 3:56 PM Doğuşcan Namal < > namal.dogus...@gmail.com > > >>> > > >>> wrote: > > >>> > > Hi Nelson, thanks for the KIP. > > > > From the RFC: > > ``` > > The authorization server MUST require the use of TLS as described in > > Section 1.6 when sending requests using password authentication. > > ``` > > > > I believe we already have an enforcement for OAuth to be enabled > only > > >> in > > SSLChannel but would be good to double check. Sending secrets over > > plaintext is a security bad practice :) > > > > +1 (non-binding) from me. > > > > On Tue, 19 Mar 2024 at 16:00, Nelson B. > > >> wrote: > > > > > Hi all, > > > > > > I would like to start a vote on KIP-1025 > > > < > > > > > > > >>> > > >> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1025%3A+Optionally+URL-encode+clientID+and+clientSecret+in+authorization+header > > >> , > > > which would optionally URL-encode clientID and clientSecret in the > > > authorization header. > > > > > > I feel like all possible issues have been addressed in the > discussion > > > thread. > > > > > > Thanks, > > > > > > > >>> > > >> > > >
Re: [VOTE] KIP-1025: Optionally URL-encode clientID and clientSecret in authorization header
Thanks for the KIP. +1 (binding) On Mon, Apr 8, 2024 at 9:49 AM Kirk True wrote: > > +1 (non-binding) > > Apologies. I thought I’d already voted :( > > > On Apr 7, 2024, at 10:48 AM, Nelson B. wrote: > > > > Hi all, > > > > Just wanted to bump up this thread for visibility. > > > > Thanks! > > > > On Thu, Mar 28, 2024 at 3:40 AM Doğuşcan Namal > > wrote: > > > >> Thanks for checking it out Nelson. Yeah I think it makes sense to leave it > >> for the users who want to use it for testing. > >> > >> On Mon, 25 Mar 2024 at 20:44, Nelson B. wrote: > >> > >>> Hi Doğuşcan, > >>> > >>> Thanks for your vote! > >>> > >>> Currently, the usage of TLS depends on the protocol used by the > >>> authorization server which is configured > >>> through the "sasl.oauthbearer.token.endpoint.url" option. So, if the > >>> URL address uses simple http (not https) > >>> then secrets will be transmitted in plaintext. I think it's possible to > >>> enforce using only https but I think any > >>> production-grade authorization server uses https anyway and maybe users > >> may > >>> want to test using http in the dev environment. > >>> > >>> Thanks, > >>> > >>> On Thu, Mar 21, 2024 at 3:56 PM Doğuşcan Namal >>> > >>> wrote: > >>> > Hi Nelson, thanks for the KIP. > > From the RFC: > ``` > The authorization server MUST require the use of TLS as described in > Section 1.6 when sending requests using password authentication. > ``` > > I believe we already have an enforcement for OAuth to be enabled only > >> in > SSLChannel but would be good to double check. Sending secrets over > plaintext is a security bad practice :) > > +1 (non-binding) from me. > > On Tue, 19 Mar 2024 at 16:00, Nelson B. > >> wrote: > > > Hi all, > > > > I would like to start a vote on KIP-1025 > > < > > > > >>> > >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1025%3A+Optionally+URL-encode+clientID+and+clientSecret+in+authorization+header > >> , > > which would optionally URL-encode clientID and clientSecret in the > > authorization header. > > > > I feel like all possible issues have been addressed in the discussion > > thread. > > > > Thanks, > > > > >>> > >> >
Re: [VOTE] KIP-1025: Optionally URL-encode clientID and clientSecret in authorization header
+1 (non-binding) Apologies. I thought I’d already voted :( > On Apr 7, 2024, at 10:48 AM, Nelson B. wrote: > > Hi all, > > Just wanted to bump up this thread for visibility. > > Thanks! > > On Thu, Mar 28, 2024 at 3:40 AM Doğuşcan Namal > wrote: > >> Thanks for checking it out Nelson. Yeah I think it makes sense to leave it >> for the users who want to use it for testing. >> >> On Mon, 25 Mar 2024 at 20:44, Nelson B. wrote: >> >>> Hi Doğuşcan, >>> >>> Thanks for your vote! >>> >>> Currently, the usage of TLS depends on the protocol used by the >>> authorization server which is configured >>> through the "sasl.oauthbearer.token.endpoint.url" option. So, if the >>> URL address uses simple http (not https) >>> then secrets will be transmitted in plaintext. I think it's possible to >>> enforce using only https but I think any >>> production-grade authorization server uses https anyway and maybe users >> may >>> want to test using http in the dev environment. >>> >>> Thanks, >>> >>> On Thu, Mar 21, 2024 at 3:56 PM Doğuşcan Namal >> >>> wrote: >>> Hi Nelson, thanks for the KIP. From the RFC: ``` The authorization server MUST require the use of TLS as described in Section 1.6 when sending requests using password authentication. ``` I believe we already have an enforcement for OAuth to be enabled only >> in SSLChannel but would be good to double check. Sending secrets over plaintext is a security bad practice :) +1 (non-binding) from me. On Tue, 19 Mar 2024 at 16:00, Nelson B. >> wrote: > Hi all, > > I would like to start a vote on KIP-1025 > < > >>> >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1025%3A+Optionally+URL-encode+clientID+and+clientSecret+in+authorization+header >> , > which would optionally URL-encode clientID and clientSecret in the > authorization header. > > I feel like all possible issues have been addressed in the discussion > thread. > > Thanks, > >>> >>
Re: [VOTE] KIP-1025: Optionally URL-encode clientID and clientSecret in authorization header
Hi all, Just wanted to bump up this thread for visibility. Thanks! On Thu, Mar 28, 2024 at 3:40 AM Doğuşcan Namal wrote: > Thanks for checking it out Nelson. Yeah I think it makes sense to leave it > for the users who want to use it for testing. > > On Mon, 25 Mar 2024 at 20:44, Nelson B. wrote: > > > Hi Doğuşcan, > > > > Thanks for your vote! > > > > Currently, the usage of TLS depends on the protocol used by the > > authorization server which is configured > > through the "sasl.oauthbearer.token.endpoint.url" option. So, if the > > URL address uses simple http (not https) > > then secrets will be transmitted in plaintext. I think it's possible to > > enforce using only https but I think any > > production-grade authorization server uses https anyway and maybe users > may > > want to test using http in the dev environment. > > > > Thanks, > > > > On Thu, Mar 21, 2024 at 3:56 PM Doğuşcan Namal > > > wrote: > > > > > Hi Nelson, thanks for the KIP. > > > > > > From the RFC: > > > ``` > > > The authorization server MUST require the use of TLS as described in > > >Section 1.6 when sending requests using password authentication. > > > ``` > > > > > > I believe we already have an enforcement for OAuth to be enabled only > in > > > SSLChannel but would be good to double check. Sending secrets over > > > plaintext is a security bad practice :) > > > > > > +1 (non-binding) from me. > > > > > > On Tue, 19 Mar 2024 at 16:00, Nelson B. > wrote: > > > > > > > Hi all, > > > > > > > > I would like to start a vote on KIP-1025 > > > > < > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1025%3A+Optionally+URL-encode+clientID+and+clientSecret+in+authorization+header > > > > >, > > > > which would optionally URL-encode clientID and clientSecret in the > > > > authorization header. > > > > > > > > I feel like all possible issues have been addressed in the discussion > > > > thread. > > > > > > > > Thanks, > > > > > > > > > >
Re: [VOTE] KIP-1025: Optionally URL-encode clientID and clientSecret in authorization header
Thanks for checking it out Nelson. Yeah I think it makes sense to leave it for the users who want to use it for testing. On Mon, 25 Mar 2024 at 20:44, Nelson B. wrote: > Hi Doğuşcan, > > Thanks for your vote! > > Currently, the usage of TLS depends on the protocol used by the > authorization server which is configured > through the "sasl.oauthbearer.token.endpoint.url" option. So, if the > URL address uses simple http (not https) > then secrets will be transmitted in plaintext. I think it's possible to > enforce using only https but I think any > production-grade authorization server uses https anyway and maybe users may > want to test using http in the dev environment. > > Thanks, > > On Thu, Mar 21, 2024 at 3:56 PM Doğuşcan Namal > wrote: > > > Hi Nelson, thanks for the KIP. > > > > From the RFC: > > ``` > > The authorization server MUST require the use of TLS as described in > >Section 1.6 when sending requests using password authentication. > > ``` > > > > I believe we already have an enforcement for OAuth to be enabled only in > > SSLChannel but would be good to double check. Sending secrets over > > plaintext is a security bad practice :) > > > > +1 (non-binding) from me. > > > > On Tue, 19 Mar 2024 at 16:00, Nelson B. wrote: > > > > > Hi all, > > > > > > I would like to start a vote on KIP-1025 > > > < > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1025%3A+Optionally+URL-encode+clientID+and+clientSecret+in+authorization+header > > > >, > > > which would optionally URL-encode clientID and clientSecret in the > > > authorization header. > > > > > > I feel like all possible issues have been addressed in the discussion > > > thread. > > > > > > Thanks, > > > > > >
Re: [VOTE] KIP-1025: Optionally URL-encode clientID and clientSecret in authorization header
Hi Doğuşcan, Thanks for your vote! Currently, the usage of TLS depends on the protocol used by the authorization server which is configured through the "sasl.oauthbearer.token.endpoint.url" option. So, if the URL address uses simple http (not https) then secrets will be transmitted in plaintext. I think it's possible to enforce using only https but I think any production-grade authorization server uses https anyway and maybe users may want to test using http in the dev environment. Thanks, On Thu, Mar 21, 2024 at 3:56 PM Doğuşcan Namal wrote: > Hi Nelson, thanks for the KIP. > > From the RFC: > ``` > The authorization server MUST require the use of TLS as described in >Section 1.6 when sending requests using password authentication. > ``` > > I believe we already have an enforcement for OAuth to be enabled only in > SSLChannel but would be good to double check. Sending secrets over > plaintext is a security bad practice :) > > +1 (non-binding) from me. > > On Tue, 19 Mar 2024 at 16:00, Nelson B. wrote: > > > Hi all, > > > > I would like to start a vote on KIP-1025 > > < > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1025%3A+Optionally+URL-encode+clientID+and+clientSecret+in+authorization+header > > >, > > which would optionally URL-encode clientID and clientSecret in the > > authorization header. > > > > I feel like all possible issues have been addressed in the discussion > > thread. > > > > Thanks, > > >
Re: [VOTE] KIP-1025: Optionally URL-encode clientID and clientSecret in authorization header
Hi Nelson, thanks for the KIP. >From the RFC: ``` The authorization server MUST require the use of TLS as described in Section 1.6 when sending requests using password authentication. ``` I believe we already have an enforcement for OAuth to be enabled only in SSLChannel but would be good to double check. Sending secrets over plaintext is a security bad practice :) +1 (non-binding) from me. On Tue, 19 Mar 2024 at 16:00, Nelson B. wrote: > Hi all, > > I would like to start a vote on KIP-1025 > < > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1025%3A+Optionally+URL-encode+clientID+and+clientSecret+in+authorization+header > >, > which would optionally URL-encode clientID and clientSecret in the > authorization header. > > I feel like all possible issues have been addressed in the discussion > thread. > > Thanks, >
