[Security Consideration] Qualitative analysis and containment of http connections to third parties

[peppelinux]

Let's assume that Alice wants to trigger a DDoS to Bob (victim website).

Alice issues a series of automatic client registration request to as many as possible OP in a multilateral federation, pretending to be bob (in request jwt, as iss). The trust chain procedure will made many HTTP requests to bob.

Security remediations that can be mentioned:

1. the outgoing HTTP request MUST be cached. Which returns with 200/30x with a short TTL. Which returns with 40x/50x with a longer one
2. Rate limit the number of outbound requests you handle. That's common HTTP request handling. Apparently nothing special for OIDC federation BUT only the application can know the nature of the request and the content of a response (404), so, given the delicacy of this problem, and the consequent attack surface that multilateral federations would introduce, I wonder where at the application level it is possible to contain (filter on the basis of content) the connections to the outside. And how to mention that in the specs

This kind of attack could affects any other kind of OAuth2/OIDC validation procedure that handle foreign connection, for example, to validate jwks and x5c

What else?

[peppelinux]

Also related to this
8.3. Revocation

[peppelinux]

Here we would find the answer about a cached approach
7.4. Calculating the Expiration Time of a Trust Chain

[peppelinux]

I think that Trust Mark could mitigate this kind of problem, especially if it could be included in the authorization request ...

[peppelinux]

Here a value proposition for Trust Marks

A RP sent an automatic client registration to an OP through a authz request with a TrustMark.
The OP first of all will verify that the claims client_id in the private_key_jwt and the sub in trust mark matches, then it will validate the trust mark with the public key of the trust anchor or intermediate (if known...).

If the trust mark is not valid the metadata discovery won't happen and the request is rejected.

---

Let's suppose that an OP have been just onboarded in a federation and it's not aware of any other intermediates.
OR
An OP have just expired the Trust Chain of a leaf.

Question
A rogue client steals a TrustMark from an existing client and draft a authz request with a spoofed client_id (that matches to TM's sub). A request sent from this rogue client to the OP will produce a metadata discovery in this latter. How many times this can happen before a prevention/ban/guided-slowing-of-responses comes in place by an OP or any other superiors?

[rohe]

The more I think about Trust marks in the authorization request the less I like the idea.
The reason is that the OP has no idea who it's talking to and there is no connection between the trust mark and the client that is secure. As you say anyone can issue an authorization request with a client_id of choice.

[peppelinux]

what about using a JWE private_key_jwt

the problem would be where to resolve that kid to public key to be used for decription.
The workaround would be using the client_id in the url params, this would let the OP to run the metadata discovery and fetch the client's key to decrypt the private_key_jwt, as a proof of possesion of the private key of the RP.

this must be done only the first time, any other next request of the RP would be validated by OP by its own, having the trust chain for that RP loaded in.

anyway this method tell us that the TM is quite useless for security considerations, if any other idea wouldn't come in place

[rohe]

Since TM was not designed to add security except secondarily by increasing the trust I'm not surprised.
The thing is that we can't use anything in the clients metadata to increase security or mitigate DDOS attacks before we have trust in the metadata. That is after we have collected and verified the trust chain.