OAuth Virtual Interim Meeting / 27.01.2025

Minute Taker: Hannes Tschofenig

Welcome (Rifaat)

Scheduled two sessions for the next IETF meeting.

OIDC Issue: private key JWT

Potential vulnerability discovered during the analysis of the OpenID
Federation specification but with applicability to OpenID Connect and
OAuth.

Audience for the private_key_jwt are not well defined in RFC 7523.
Other specifications added further clarifications, such as PAR (RFC
9126), JAR (RFC 9101).

Joseph explained the steps of the attack based on a Fintech example. For
the attack to be successful, one of the banks has to become malicious.

Mike continues with a discussion of possible solutions, which includes:

• audience = issuer
• audience = target endpoint
• new claim

Solution among a small group is "audience = issuer". Already used by
various specs, including JAR, PAR, OpenID FAPI 2, OpenID Federation,
OAuth iss parameter.

What documents need to be updated:

• RFC 7523 (update: AS issuer identifier is the only identifier used)
• RFC 7521 (Assertion Framework)
• RFC 7522 (SAML assertions)
• RFC 9101 (JAR)
• RFC 9126 (PAR)
• OAuth security BCP

Then, there are various OpenID specs.

Mike asked the question whether there are other security issues that
need to be incorporated into these updates.

Should the security vulnerability and the mitigation be described in the
document?

Justin: We cannot hold the security BCP every time a security issue
comes up. Regarding the -bis document, I would update the whole document
rather than publishing a draft that just contains the new text. This
should not be a long process, if we stick to the scope.

Daniel: I would like to know whether the group wants to add something to
the security BCP or not.

Brian: The scope creep is real. Let the security BCP go. The changes for
RFC 7523-bis should be smaller than what Mike proposed.

Joseph DeCock: I want to come back to the vulnerability disclosure ask.

We would like to release a new version of our identity server and want
to publish why we do this. How should we do this?

Mike: Tell people that this closes a security vulnerability and not to
provide detailed description of how to exercise the vulnerabilities.
This requires a certain amount of trust from your customers.

Joseph Heenan: You could say that you are making the update for
compatibility to FAPI specification.

Mike: Do we make the update to the audience for the assertion grant?

Mike: Does the vulnerability also applied to other assertion grants? The
short answer is yes but it is not actionable.

Justin: We can do a quick -bis. Adding text after the WGLC to the
security BCP that is large (like a new attack) is not what I would do.

Filip: I would like to respond to Joseph DeCock - the AS change is not
what closes the vulnerability. The fix is clients doing the right thing.
This should have been explained better. There is no need to rush the AS
changes.

Joseph Heenan: The real AS does not know that is under attack.

Filip: Brian wrote it correctly "the AS changes only kinda help flush
out clients that are not doing the right thing".

Mike: Thanks the group.

Rifaat is asking whether anyone wants to delay publication of the
security BCP any longer.

-- nobody raised his or her hands --

Rifaat: Publish RFC 7523-bis as an individual document and then we will
ask the working group about the right scopes.

Hannes thanks the group for the work on this difficult issue and to
Deb&Roman for their support.