Security Issue - Attacker may reuse MS to register new clients

[Andreas Åkre Solberg]

In the current OpenID Connect Federation spec 5.2 describes the process of using dynamic relying party registration

https://openid.net/specs/openid-connect-federation-1_0.html#rfc.section.5.2

The client registration request is not signed, instead it contains a a signed MS. The MS does not contain a client_id, nor is it aimed towards a specific OP. The MS may be used as a kind of bearer token credentials granting access to register new clients - those clients will be restricted with the content of the MS.

The MS-es could be considered public, usually hosted at non-protected HTTP endpoints (metadata_statement_uri etc). The MS is also sent to OPs during registration.

Attackers that get hold of an MS may use that to register new clients at providers.

This needs to be discussed, but there is no obvious easy way to fix this.

The evil OP can use the public MS to register new clients at other providers. Then it will get a set of client_id and client_secrets that other OPs thinks it has issed to the real client. But the registration will be locked to the redirect_uri of the client, and the OP cannot change that value.

How is this still bad?

• An OP may find it useful to provide clients access to perform certain operations with userless tokens, using client credentials flow. Here the redirect_uri is not used. This could be things like modifying the client registration. It can be getting user statitics, and more.
• An OP may not accept the real client registers, because it is already registered. And it may require an registration access token, that is given away to the evil OP.
• An OP may want to protect access tokens from being exposed to end users. The acess token may give far more access than what the end users should have (this is a bad design, but nontheless). The OP may achive this protection by only used authorization code flow, and require client_id / client_secret pair to obtain the token. An end user using an evil OP to obtain a client / secret pair may then also get its own user token.
• And in certain cases redirect_uri could also lack the strict binding to the control of the real client. In examples native mobile applications may register the redirect_uri of coolapp://, but it could not restrict other apps from registering the same custom scheme with Android or iOS. The same goes for native desktop applications. And CLI tools may use localhost:9871 as redirect_uri…

[Roland Hedberg]

As you hinted in Issue1042 one thing we can do is to demand that the complete client request should be self-signed.

The draft specifies OpenID Connect as the basis so client credential flow is out-of-scope.

To deal with not being the real client that registers we may have to add some proof-of-possesion exchange where the client shows that it controls the metadata signing keys.

[Roland Hedberg]

I thought I had added another comment but it got lost somewhere.

Anyway, in the signed JSON Web Token there is an aud defined. That aud MUST be the OP's issuer ID. another check that should be added to the verification of the client registration request.

I think this should make it harder for the evil OP to do what Andreas describes.

[Michael Jones]

Roland, please add the checks that you're describing in your comment.

[John Bradley]

The software statement should contain a proof of possession. For any sort of auth not involving ;locking down the redirect URI , the client authentication should be asymmetric with the JWKS URI specified or the public key directly provided in the Software statement.
It would be preferable to lock down authentication even if there is a redirect URI specified.

[Roland Hedberg]

Client registration can be done in 2 ways.

1. Explicit client registration
2. Automatic client registration

Which ever one is used they both depends on the OP getting (explicit) or fetching (automatic) a self-signed entity statement that belongs to the client. The OP MUST verify that the entity statement belongs to a client that is part of the federation by checking the trust chain and at the same time check that the entity statement has not been tampered with. Sure an entity could get hold of an entity statement and use it in a client registration but it would not be able to modify the information in the entity statement to make itself a client in the federation.

[Vladimir Dzhuvinov]

In explicit client registration we can require the aud in the stmt to be set to the OP issuer. Right now (draft 12) the aud is optional:

https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc.section.2.1

[Roland Hedberg]

Requiring aud in the entity statement is added in draft 13.