insecure front-channel use of private_key_jwt client authentication

[Brian Campbell]

“At a minimum openid-connect-federation needs to acknowledge that it's misusing private_key_jwt and do something to mitigate the security problem.”

Please see https://github.com/oauthstuff/draft-oauth-par/issues/41 but particularly the comments at https://github.com/oauthstuff/draft-oauth-par/issues/41#issuecomment-615081283 and https://github.com/oauthstuff/draft-oauth-par/issues/41#issuecomment-615475230

‌

‌

‌

[Michael Jones]

This has received substantial on-list discussion and I believe Roland Hedberg has a plan of action.

[Brian Campbell]

that on-list discussion is here http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20200420/thread.html fwiw

‌

[Brian Campbell]

draft -12 https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc.section.9.1.1.1 is now using the request object as one option. However, it requires ‘sub’ saying “The claim sub MUST contain the entity ID of the OpenID Connect provider.” I assume that’s a mistake and should have said it’s the the client identifier? That’d make more sense and is what the content of the example has. The same presumably erroneous text is there for ‘iss’ too.

But WHY is sub required? The same data would already be carried in the ‘iss’ claim and the ‘client_id’ claim and the ‘client_id’ parameter. Worse the ‘sub’ claim means that the request JWT could likely be used as a private_key_jwt in a token confusion type attack as discussed in https://github.com/oauthstuff/draft-oauth-par/issues/41#issuecomment-615475230 and subsequent comments. So the problem at the heart of this issue is still present.

‌

[Brian Campbell]

Also -12 references an old and expired PAR draft https://openid.net/specs/openid-connect-federation-1_0-12.html#PAR and https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc.section.3.2 has “URL of the Authorization Server's Authorization Endpoint or the Authorization Server's entity_id” (note ‘entity_id’ isn’t used anywhere else) for the ‘aud’ of private_key_jwt, which isn’t consistent with the below text from https://www.ietf.org/id/draft-ietf-oauth-par-01.html#section-2 :

“Note that there's some potential ambiguity around the appropriate audience value to use when JWT client assertion based authentication is employed. To address that ambiguity the issuer identifier URL of the AS according to [RFC8414] SHOULD be used as the value of the audience. In order to facilitate interoperability the AS MUST accept its issuer identifier, token endpoint URL, or pushed authorization request endpoint URL as values that identify it as an intended audience.“

‌

[Roland Hedberg]

Fixed the PAR reference.

[Roland Hedberg]

Regarding the entity statement use for automatic client registration we now specify that ‘sub’ MUST NOT be part of the statement and that ‘aud’ MUST be the ASs authorization endpoint URL.