Session Date/Time: 27 Jan 2025 17:00

OAUTH

Summary

This interim meeting focused on a newly identified security vulnerability in the Private Key JWT client authentication method. The vulnerability stems from ambiguities in the aud (audience) claim definition across several OAuth and OpenID Connect specifications, potentially allowing an attacker to replay client assertions. The discussion covered the technical details of the attack, its preconditions, proposed mitigations, and the necessary updates to affected specifications. Key points of debate included the scope of a proposed "bis" document for RFC 7523 and whether to incorporate this vulnerability into the already-published oauth-security-bcp.

Key Discussion Points

Vulnerability Disclosure and Sensitivity:
- The vulnerability was discovered during a security analysis of OpenID Federation by the University of Stuttgart (Bedem, Tim, Ralph).
- While initially found in OpenID Federation, it has wider ecosystem impact beyond Federation.
- No live ecosystems are currently known to be vulnerable, but responsible disclosure is being pursued.
- Participants were asked to exercise caution in publicizing detailed exploit information to allow time for mitigation implementation. The session itself is public and recorded.
- A link to the full academic paper describing the exploit was shared in the chat, with a request not to share it publicly to limit actionable exploitation.
Historical Ambiguity of aud Claim in Private Key JWT:
- RFC 7523 (OAuth 2.0 JWT Bearer Token Usage) defines the aud value vaguely, stating it "must be a claim containing a value that identifies the authorization server as an intended audience." It allows multiple values and suggests the token endpoint URL "may be used."
- OpenID Connect Core is similarly vague, suggesting aud "should be the authorization server's token endpoint."
- This ambiguity has led to inconsistent interpretations and implementations, creating the vulnerability.
The Attack (Replay Vulnerability):
- An attacker controls an Authorization Server (AS) within an ecosystem (e.g., Open Banking).
- The attacker-controlled AS advertises its token endpoint URL as the issuer URL of a legitimate AS.
- A legitimate client, when interacting with the attacker-controlled AS (e.g., via PAR), sends a Private Key JWT assertion.
- Due to the ambiguous aud definition, the client might set the aud claim to the real AS's issuer URL (which the attacker advertised as their token endpoint).
- The attacker captures this assertion.
- The attacker can then replay this captured assertion to the real AS's token endpoint, authenticating as the legitimate client, because the aud claim matches the real AS's issuer identifier.
Preconditions for the Attack:
- Lack of mTLS (Mutual TLS) binding the client certificate to the client ID, as mTLS would prevent replay.
- The attacker needs to control an AS that is trusted by the legitimate client, implying a high bar for the attacker (e.g., infiltrating a regulated ecosystem).
- At least two endpoints with client authentication (e.g., PAR and Token endpoint) are required to create the aud mismatch.
- The client ID needs to be the same across both AS (attacker-controlled and legitimate), or the attacker must influence client ID issuance.
Proposed Mitigation Strategy:
- The consensus among the initial ad-hoc group was to require the Authorization Server's issuer identifier (as defined in RFC 8414) to be the only aud value for JWTs sent to the AS.
- This aligns with more recent OAuth/OpenID Connect specifications (e.g., FAPI 2, OpenID Federation) and the iss parameter usage.
- Explicit typing (e.g., using the typ JWT header) was suggested by Philip Skogen as a mechanism for AS to distinguish between old and new clients for compatibility during transition.
Affected Specifications and Proposed Updates (via 7523bis or Errata):
- RFC 7523 (oauth-jwt-bearer): Proposed "bis" document (7523bis) would replace it, requiring the AS issuer identifier as the only aud value.
- RFC 7521 (oauth-assertion-framework): 7523bis would update this by replacing a paragraph.
- RFC 7522 (oauth-saml-bearer): 7523bis would tighten the aud language.
- OpenID Connect Core: Proposed errata to update aud from token endpoint URL to AS issuer identifier.
- FAPI 1: Proposed errata to make AS issuer identifier the only aud value (currently allows multiple).
- FAPI 2: Already requires the AS issuer identifier as the only aud value.
- OpenID Federation: Already updated to tighten aud.
- CIBACore (OpenID Foundation): Already updated by Joe Deak to tighten aud.
- oauth-jar: 7523bis would change the should requirement for aud (AS issuer) to a must.
- oauth-par: 7523bis would change it from mandating acceptance of three aud values to accepting only the AS issuer identifier.
- oauth-security-bcp: Discussion on whether to insert a new clause describing this vulnerability and its mitigation before the BCP is published as an RFC.
Discussion on Security BCP and Scope of 7523bis:
- Security BCP: Justin Richer and Daniel Fett argued that pausing the oauth-security-bcp for new additions would indefinitely delay its publication. They suggested publishing it as is and addressing new vulnerabilities in a subsequent revision. The sentiment was to publish the BCP now.
- Scope of 7523bis: Brian Campbell expressed concern that the proposed 7523bis is too broad, touching specifications (e.g., JAR, assertion grants) that are not directly related to the vulnerability and could cause significant churn, discussion, and interoperability issues. He advocated for a much narrower scope. Mike Jones argued for consistency in aud validation rules across all token types for simplicity.
Client vs. Server Fix:
- Philip Skogen emphasized that the fundamental fix lies with clients implementing the correct behavior (i.e., sending the AS issuer identifier as the aud).
- Authorization server changes that reject incorrect aud values are valuable for "flushing out" misconfigured clients but do not directly prevent the attack if clients are still sending incorrect aud values to an attacker-controlled endpoint.

Decisions and Action Items

Decision: The oauth-security-bcp will not be held back or amended for this vulnerability. It will proceed to publication. New security issues will be addressed in a future revision of the BCP.
Action Item: Mike Jones to publish the 7523bis draft as an individual submission.
Action Item: Mike Jones to push the 7523bis draft to the OAUTH mailing list to facilitate discussion on its scope and specific changes before a working group adoption call is made.
Action Item: Mike Jones to publish a draft of the OpenID Connect Core errata update after the call.
Action Item: Mike Jones to consult with the MANNA working group editors and chairs regarding publishing the CIBACore update.

Next Steps

The OAUTH working group will engage in detailed discussion on the mailing list regarding the scope and contents of the proposed 7523bis document.
The chairs will schedule a future meeting to conduct a postmortem analysis on how to avoid similar issues in specification development.
IETF leadership is supportive of potentially accelerating the publication of these "bis" documents once their scope and content are finalized.
The upcoming IETF meeting in Bangkok will feature two OAUTH working group sessions, reduced from the typical three due to this series of interims.