Add Security sub-section of DOS risks

[identitymonk]

I think there are two DOS risks on the authorization endpoint (and other endpoints that could accept CIMD as parameter) that might worth spelling it out in the security section of this specification:

• I could force through multiple authorization requests to an AS with CIMD hosted at a slow responding endpoint mobilizing resources at the AS up to a DOS situation

** Proposed text **

Client ID Metadata Document Fetch DOS

Authorization servers fetching client metadata documents SHOULD implement appropriate rate limiting and timeout mechanisms
when retrieving Client ID Metadata Documents. A malicious actor could attempt to cause a denial of service by initiating multiple
authorization requests using a client_id that points to an intentionally slow-responding endpoint, potentially exhausting authorization server resources.

Authorization servers SHOULD implement measures from this non exhaustive list:
- implement standard anonymous and bad reputation IP filtering, as well as DNS name filtering
- Implement strict timeouts when fetching metadata documents
- Rate limit requests per client_id URL and/or requesting IP
- Consider caching valid responses as specified in Section 4.4
- Terminate requests that exceed reasonable response times

• I could force through multiple authorization requests to an AS to fetch what could be CIMD at 3rd party, mobilizing resources at this 3rd party up to a DOS situation

** Proposed text **

Third-Party Endpoint DOS Protection

Authorization servers MUST take precautions to prevent their metadata document fetching mechanism from being used as an
amplification vector in DOS attacks against third-party endpoints. A malicious actor could attempt to use the authorization
server's metadata fetching capabilities to direct high volumes of requests to an arbitrary third-party target.

Authorization servers SHOULD implement measures from this non exhaustive list:
- implement standard anonymous and bad reputation IP filtering
- Implement per-endpoint rate limiting for metadata document fetches
- Monitor for patterns of repeated requests to the same endpoints
- Consider maintaining allow-lists and deny-lists of trusted domains for metadata documents
- Implement circuit breakers to prevent cascading failures

[ThisIsMissEm]

I think many of these mitigations are just general OAuth security recommendations?

Yes, we could do with a security consideration section on timeouts, but those are very deployment specific as to what makes sense for your deployment. The most we could probably say is that as you're making an outbound HTTP request, to ensure that you set appropriate timeouts around making that request.

As for the DOS aspect, a lot of these can be mitigated by deferring the fetching of the Client ID Metadata Document until after the user is logged in, i.e., not fetching the document the moment you receive the authorization request or PAR.

[identitymonk]

Yes and no. Yes, those are standard web endpoint mitigations but fetching "per authorization request" is really a stance that was not approach until now in OAuth.

I like"deferring the fetching of the Client ID Metadata Document until after the user is logged in" as a MUST, while the rest might remain an Informative Guidance.

[ThisIsMissEm]

I like"deferring the fetching of the Client ID Metadata Document until after the user is logged in" as a MUST, while the rest might remain an Informative Guidance.

This does change the error handling situation here, for instance, a poorly formed Client ID Metadata Document then likely gives the user a dead-end in the authorization flow, especially with PARs.

I know Aaron has a separate issue with a recommendation to only fetch documents after login.

[identitymonk]

This does change the error handling situation here, for instance, a poorly formed Client ID Metadata Document then likely gives the user a dead-end in the authorization flow, especially with PARs.

Agreed but it gates abuse attempts through a valid user authentication. Having a user succeeding in authentication but with invalid CIMD is another type of signal that the user might be compromised.