Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments
The current draft (draft-ietf-oauth-dpop-01) does say that when a valid DPoP proof is presented and refresh token is issued to a public client, the refresh token must be bound to the DPoP key. So that part is already covered in the document. And, for whatever it's worth, that pretty closely mirrors how it works with MTLS, public clients, and RTs. If there are specific suggestions as to how to make it more clear, they'd of course be welcome. The text in draft does need to be updated to better account/allow for, as Justin said, the "AS could still decide to issue a Bearer token, using the token_type field, for whatever policy reason." I'd sort of thought it already did and it was the intent but, on reading again, there's definitely some text that needs to be fixed. That should help better facilitate mixed or rollout deployments by letting the AS decide to bind ATs or not based on resource or scope requested or other policy. Also to help facilitate mixed or rollout deployments, I'm not sure about "An client should never send a DPoP [bound access] token as a Bearer header." Such a constraint could be put on the client but it seems unhelpful. A bad acting client could easily ignore it and I'm not sure what it accomplishes if/when followed. Following from https://github.com/danielfett/draft-dpop/issues/58 the draft needs to be updated to say explicitly that an RS supporting both Bearer and DPoP schemes simultaneously needs to update its Bearer token evaluation functionality so as to reject tokens that are dpop bound. But the draft can't really impose anything on existing RSs supporting only Bearer (and unaware of DPoP). And such RSs will most likely accept a DPoP bound AT when send via the Bearer scheme (JWT says to ignore unrecognized claims, introspection says other parameters might be present, and 6750 is basically silent on the content of the AT, which is where the binding is carried). This admittedly doesn't seem quite right. But there's nothing this draft can realistically do about it. And I think it can help with mixed or rollout deployments. Especially those where sufficient information about what RS(s) the requested token is for are not available in the token request for whatever reason. Currently the draft is silent about it and maybe that's as it should be. But I'm suggesting in a few messages on this thread that the definition of the DPoP token_type would prescribe sending the access token with the DPoP authorization scheme in conjunction with the DPoP header but also say that, if that was met with a 401 WWW-Authenticate: Bearer challenge by a particular RS (or the client had prior such knowledge about the RS), that the access token could be sent using the Bearer authorization scheme. It is correct that, as currently written in the draft, a public client with a DPoP bound refresh token will have to use the same key for the lifetime of the grant. That seemed like a good tradeoff vs. defining a mechanism for key rotation for the public client refresh token case where two proofs (one to verify the binding for the RT being sent and one to newly bind the RT to) would be presented on refresh grant type request. I tend to think where it is now hits the right balance in functionality and complexity. But if there are strong beliefs otherwise, let's discuss the need and cost/benefit and all that. On Thu, Jun 11, 2020 at 1:26 AM Neil Madden wrote: > +1 > > > On 11 Jun 2020, at 07:36, Torsten Lodderstedt 40lodderstedt@dmarc.ietf.org> wrote: > > > > I generally agree with the proposal, but I would suggest to limit it to > public clients. > > > > In case of confidential clients, the refresh token is (via the > client_id) already bound to the client’s secret(s) and those can be > rotated. Additionally binding the refresh token to a DPoP key would limit > it’s applicability w/o a benefit. > > > >> On 11. Jun 2020, at 01:35, Francis Pouatcha wrote: > >> > >> > >> On Wed, Jun 10, 2020 at 4:32 PM Justin Richer wrote: > >> What if we simply declare that refresh tokens are always bound to the > DPoP key used to request them? Is there value in NOT binding the refresh > token? > >> > >> Fully agree. I will add a refresh_token shall always be PoP bound. > Independent of the type of PoP. > >> > >> As for access tokens, the way I read it, all of this is true: > >> > >> - The AS could still decide to issue a Bearer token, using the > token_type field, for whatever policy reason. > >> - A client getting back a Bearer token from a DPoP request would do > Bearer headers. > >> - A client getting a DPoP token from a DPoP request would do DPoP > headers. > >> - An client should never send a DPoP token as a Bearer header. > >> - An RS should ALWAYS look for a DPoP binding signature from a DPoP > scheme token. Missing that is an error. > >> > >> So if we just declare that a refresh token must always be DPoP bound > when DPoP is used to request it and a refresh token is issued, then we’re > in the clear here, as best a
[OAUTH-WG] Fwd: Nomcom 2020-2021 Second Call For Volunteers
Please, consider volunteering for this role. Regards, Rifaat -- Forwarded message - From: NomCom Chair 2020 Date: Wed, Jun 10, 2020 at 2:55 PM Subject: Nomcom 2020-2021 Second Call For Volunteers To: IETF Announcement List Cc: This is the second sending of the call for volunteers for the 2020-2021 NomCom. I wanted to mention a few updates from the previous email (sent 2 weeks ago): - I've fixed the URL at the bottom of the email to point to https://datatracker.ietf.org/nomcom/2020/ instead of /2019/. This was a test to see if anyone was paying attention. Apparently, some people were. ;) - The IETF 108 registration form includes a checkbox that will let you volunteer. You can use this instead of emailing me, when you register for IETF 108. - I currently have 39 volunteers. Last year had 149. I need more volunteers! - The IETF NomCom appoints people to fill the open slots on the LLC, IETF Trust, the IAB, and the IESG. Ten voting members for the NomCom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. The details of the operation of the NomCom can be found in BCP 10 (RFC 8713). RFC 3797 details the selection algorithm. Special for this year (and only this year), we also have RFC 8788 (one-off update to RFC 8713 / BCP 10) to tell us who is eligible to volunteer: Members of the IETF community must have attended at least three of the last five in-person IETF meetings in order to volunteer. The five meetings are the five most recent in-person meetings that ended prior to the date on which the solicitation for NomCom volunteers was submitted for distribution to the IETF community. Because no IETF 107 in-person meeting was held, for the 2020-2021 Nominating Committee those five meetings are IETFs 102 [Montreal, Canada; July 2018], 103 [Bangkok, Thailand; November 2018], 104 [Prague, Czech Republic; March 2019], 105 [Montreal, Canada; July 2019], and 106 [Singapore; November 2019]. Keep in mind that eligibility is based on in-person attendance at the five listed meetings. You can check your eligibility at: https://www.ietf.org/registration/nomcom.py. If you qualify, please volunteer. Before you decide to volunteer, please remember that anyone appointed to this NomCom will not be considered as a candidate for any of the positions that the 2020 - 2021 NomCom is responsible for filling. People commonly volunteer by ticking the box on IETF registration forms. The IETF 106 form did not ask whether people were willing to volunteer. IETF 107 did ask, but all those registrations were canceled. I have asked the Secretariat if it is possible to get the list if volunteers from canceled IETF 107 registrations. If that list is available, I will contact all who are verified as eligible. But given the uncertainty of this process, I would encourage people to volunteer directly (see the bottom of this email for instructions). Thank you for volunteering! The list of people and posts whose terms end with the March 2021 IETF meeting, and thus the positions for which this NomCom is responsible, are IETF Trust: Joel Halpern LLC: Maja Andjelkovic IAB: Jari Arkko Jeff Tantsura Mark Nottingham Stephen Farrell Wes Hardaker Zhenbin Li IESG: Alissa Cooper, IETF Chair/GEN AD Alvaro Retana, RTG AD Barry Leiba, ART AD Deborah Brungard, RTG AD Éric Vyncke, INT AD Magnus Westerlund, TSV AD Roman Danyliw, SEC AD Warren Kumari, OPS AD All appointments are for 2 years. The Routing area has 3 ADs and the General area has 1; all other areas have 2 ADs. Thus, all areas (that have more than one AD) have at least one continuing AD. The primary activity for this NomCom will begin in July 2020 and should be completed in January 2021. The NomCom will have regularly scheduled conference calls to ensure progress. There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. While being a NomCom member does require some time commitment it is also a very rewarding experience. As a member of the NomCom it is very important that you be willing and able to attend either videoconference or in-person meetings (which may not happen) during 14-20 November (IETF 109 - Bangkok) to conduct interviews. Videoconference attendance will be supported whether or not there are in-person meetings. Orientation and setting of the NomCom schedule will be done by videoconference during the week 20-24 July (exact time and date to be determined after NomCom membership is finalized on July 12), the week prior to IETF 108. Being at IETF 110 (Prague) is not essen
Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments
> On 11. Jun 2020, at 19:24, Francis Pouatcha > wrote: > > > > On Thu, Jun 11, 2020 at 3:26 AM Neil Madden wrote: > +1 > > > On 11 Jun 2020, at 07:36, Torsten Lodderstedt > > wrote: > > > > I generally agree with the proposal, but I would suggest to limit it to > > public clients. > > > > > In case of confidential clients, the refresh token is (via the client_id) > > already bound to the client’s secret(s) and those can be rotated. > > Additionally binding the refresh token to a DPoP key would limit it’s > > applicability w/o a benefit. > I meant PoP and not DPoP. The client secret is also a variant of PoP. This > does not change the value of this sentence: "refresh_token shall always be > bound to a PoP". This means you agree DPoP shall be used for refresh tokens issued to public clients only? As you said, client authentication is a kind of PoP as well, so confidential clients don’t need DPoP protection for refresh tokens. > > -- > Francis Pouatcha > Co-Founder and Technical Lead at adorys > https://adorsys-platform.de/solutions/ smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments
On Thu, Jun 11, 2020 at 3:26 AM Neil Madden wrote: > +1 > > > On 11 Jun 2020, at 07:36, Torsten Lodderstedt 40lodderstedt@dmarc.ietf.org> wrote: > > > > I generally agree with the proposal, but I would suggest to limit it to > public clients. > > > > > In case of confidential clients, the refresh token is (via the > client_id) already bound to the client’s secret(s) and those can be > rotated. Additionally binding the refresh token to a DPoP key would limit > it’s applicability w/o a benefit. > I meant *PoP* and not *DPoP*. The client secret is also a variant of PoP. This does not change the value of this sentence: "*refresh_token shall always be bound to a PoP*". -- Francis Pouatcha Co-Founder and Technical Lead at adorys https://adorsys-platform.de/solutions/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments
+1 > On 11 Jun 2020, at 07:36, Torsten Lodderstedt > wrote: > > I generally agree with the proposal, but I would suggest to limit it to > public clients. > > In case of confidential clients, the refresh token is (via the client_id) > already bound to the client’s secret(s) and those can be rotated. > Additionally binding the refresh token to a DPoP key would limit it’s > applicability w/o a benefit. > >> On 11. Jun 2020, at 01:35, Francis Pouatcha wrote: >> >> >> On Wed, Jun 10, 2020 at 4:32 PM Justin Richer wrote: >> What if we simply declare that refresh tokens are always bound to the DPoP >> key used to request them? Is there value in NOT binding the refresh token? >> >> Fully agree. I will add a refresh_token shall always be PoP bound. >> Independent of the type of PoP. >> >> As for access tokens, the way I read it, all of this is true: >> >> - The AS could still decide to issue a Bearer token, using the token_type >> field, for whatever policy reason. >> - A client getting back a Bearer token from a DPoP request would do Bearer >> headers. >> - A client getting a DPoP token from a DPoP request would do DPoP headers. >> - An client should never send a DPoP token as a Bearer header. >> - An RS should ALWAYS look for a DPoP binding signature from a DPoP scheme >> token. Missing that is an error. >> >> So if we just declare that a refresh token must always be DPoP bound when >> DPoP is used to request it and a refresh token is issued, then we’re in the >> clear here, as best as I can tell, and it allows the AS some flexibility. >> >> Some problems with this: >> >> 1) Pretty much every single OAuth client in the world ignores the >> “token_type” field. But clients being updated to support DPoP wouldn’t >> ignore it, so that’s probably ok. >> 2) If we wanted to make refresh token binding switchable we’d need a >> “refresh_token_type” field or similar, and the client would need to know how >> to understand it and deal with its absence (since most servers won’t send >> it). >> 3) This presumes the client will not rotate its key before using the refresh >> token. If it does it’ll have to do a whole new grant. >> 4) None of this prevents an RS from ignoring the DPoP signature, but I think >> that’s a separate problem. >> 5) It’s arguable that we’d want a client to be able to bind a NEW DPoP key >> during a refresh, using the old key as proof for the refresh token and the >> new key going forward. Is this a case we want to enable? >> Key rotation shall be handled separately from the refresh_token process. If >> a refresh_token is bound to a key, the client shall keep that key till the >> refresh_token is consumed. A key rotation process shall be designed such as >> to allow the key holder to keep obsolete keys for the completion of pending >> processes. >> >> — Justin >> On Jun 7, 2020, at 3:22 AM, Torsten Lodderstedt wrote: >>> >>> That’s correct for confidential clients. >>> >>> For a public client, the refresh token is just bound to the client id. DPoP >>> allows binding to an ephemeral key pair for this kind of clients. >> >> >> -- >> Francis Pouatcha >> Co-Founder and Technical Lead at adorys >> https://adorsys-platform.de/solutions/ > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
