On Fri, Feb 7, 2025 at 7:37 PM Michael Jones <michael_b_jo...@hotmail.com> wrote:
> We agree on starting with a single document and on producing something > that addresses the issues in a timely and responsible manner. > > > > We disagree that the current document is correctly scoped to do so. > > > > As background, when asked, the Stuttgart security researchers who > identified the vulnerability also told us that the authorization grant is > vulnerable to the same attacks. That’s why the draft also fixes the > audience for these tokens. > I was party to that conversation and what was described in telling us how the authorization grant is vulnerable was sufficiently contrived to the point of being vanishingly unrealistic (involving a 'local' AS doing token exchange with the client using different 'remote' AS's including one that is malicious). > > > We should fix all the vulnerabilities in a consistent manner, rather than > picking and choosing which to fix and having to come back and fix more > later. > > > > I'll also note that any potential interop problems are mitigated Filip > Skokan’s suggestion to explicitly type the tokens, which the draft does. > Your code can know that you're using rfc7523bis tokens when they're > explicitly typed and you'll know that you aren't when they aren't. Code can > continue to allow the old behaviors when explicit types aren't present, if > the context is such that the security risks are acceptable. > Filip's suggestion was for JWT client auth FWIW and explicitly typing the tokens provides some visibility and controls into the interop problems but does not make them go away. It also can't really be applied to SAML because there's no equivalent construct in a SAML assertion to the typ header in JWS/JWT. And it doesn't work for request objects because RFC 9101 already has a media type defined. I view the current draft as a practical means to close all the identified > vulnerabilities in a timely manner with minimum disruption to deployments. > > > > -- Mike > > > > *From:* Brian Campbell <bcampb...@pingidentity.com> > *Sent:* Friday, February 7, 2025 10:24 AM > *To:* Filip Skokan <panva...@gmail.com> > *Cc:* Michael Jones <michael_b_jo...@hotmail.com>; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Re: draft-jones-oauth-rfc7523bis published and > questions to the working group > > > > Thanks for the work on this document Mike. Regarding the questions for the > working group: > > 1. My preference is for a single document. > 2. The scope of the changes should be constrained to only what is > necessary to address the issue that brought us here, which is JWT Client > Assertion Authentication. Updates beyond that scope will needlessly > introduce confusion and interoperability problems as well as maintenance > and support burden and/or unnecessarily hinder progress of the work. > 3. I would like to see the WG produces something that address the > issue in a timely and responsible manner. The current draft is not well > positioned to do either. > > > > > > > > > > On Fri, Jan 31, 2025 at 8:57 AM Filip Skokan <panva...@gmail.com> wrote: > > Hello Mike, > > > > thank you for a quick turnaround on these > > > > As far as questions 1-3 go: > > > > 1. I believe a precise incision in the form of a single "bis" document > is fine but if these were individual documents it wouldn't hurt, > whatever we can get out the door faster. > 2. We have not done the homework of understanding the impact of > changing anything but client authentication JWTs. > > > 1. Ad JAR) There's no conflicting definition that would mention > anything but using RFC8414 issuer in RFC9101 and so I am in favour of > leaving it be in its current pre-bis state as the only change would be > forbidding the array style of audience. It is unnecessary. In the client > auth case we have conflicting definitions with MAY and SHOULD about the > token endpoint being used; We don't have that in JAR. > 2. Ad authorization grant JWTs) Aaron pointed out in prior > discussions that these would better remain unchanged [^1], is that still > the case? > 3. Ad SAML) I cannot imagine any changes being done here but will > admit that I would leave this with others who better understand how SAML > assertions are used today. > 4. Bottom line I hope we can deal with just the issue at hand and > avoid changes to unaffected assertions. > > > 3. Doesn't it sort of hinge on what we believe the right answer to 1) > is? > > [^1]: Question for Aaron, if authorization grant JWTs remained as is wrt. > to the audience claim, what about the added "typ"? > > > > S pozdravem, > *Filip Skokan* > > > > > > On Thu, 30 Jan 2025 at 20:03, Michael Jones <michael_b_jo...@hotmail.com> > wrote: > > I’ve published draft-jones-oauth-rfc7523bis > <https://www.ietf.org/archive/id/draft-jones-oauth-rfc7523bis-00.html>, > which proposes replacing RFC 7523 <https://www.rfc-editor.org/rfc/rfc7523> > (JWT Assertions) and proposes corresponding updates to RFC 7521 > <https://www.rfc-editor.org/rfc/rfc7521> (Assertions Framework), RFC 7522 > <https://www.rfc-editor.org/rfc/rfc7522> (SAML Assertions), RFC 9101 > <https://www.rfc-editor.org/rfc/rfc9101> (JAR), and RFC 9126 > <https://www.rfc-editor.org/rfc/rfc9126> (PAR), as discussed during > Monday’s interim. See the deck that Joseph Heenan and I presented > <https://datatracker.ietf.org/meeting/interim-2025-oauth-04/materials/slides-interim-2025-oauth-04-sessa-private-key-jwt-aud-issues-00.pdf> > . > > > > Note that corresponding updates have also been published to OpenID Connect > Core, OpenID FAPI 1, OpenID FAPI 2, and OpenID CIBA Core. > > > > The discussion on Monday resulted in these questions for the working group: > > > > 1. The draft proposes to update affected specs other than RFC 7523, > rather than replacing them. This was done to make the changes easier to > review. See the four sets of updates beginning at Section 9 > > <https://www.ietf.org/archive/id/draft-jones-oauth-rfc7523bis-00.html#name-updates-to-rfc-7521>. > Do we want to update the affected specs from this single “bis” document or > create individual “bis” documents for each of them? > 2. The draft proposes to uniformly update the audience values in > security tokens sent to the authorization server to the AS’s issuer > identifier. This includes client authentication JWTs, authorization grant > JWTs, and Request Object JWTs. This is a change in some cases and a > narrowing to a single already-acceptable specified audience choice in > others. Do we want to uniformly use the issuer identifier for token > audiences, or have a different special case audience value of the token > endpoint URL for authorization grant JWTs? > 3. Are people in favor of adopting the draft as-is and then making any > changes wanted by the working group to the adopted spec or are there > specific changes people believe we should make before adoption? As a > reminder (quoting from an IETF call for adoption), “Adoption does not mean > a document is finished, only that it is an acceptable starting point.” > > > > Thanks to all who put in substantial work over the last few months to get > us to this point! > > > > -- Mike > > > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
