[Federation] trust mark hint in the authz request

[Giuseppe De Marco]

We have worked on the security consideration in the Fed specs here.
These highlighted how the trust marks can be adopted as a remediation against the propagation attacks of http requests.

An OP before validating a trust mark must fetch the entity configuration of the RP, and this means that the OP must start a http request to the RP’s .well-known/openid-federation endpoint.

We may consider the possibility to avoid also this connection if a valid trust marks are available in the authz request. An OP may check for the presence of a valid trust mark before fetching the RP’s EC.

this issue was inspired by some consideration exposed during the GAIN PoC meeting and also by these issues:

https://bitbucket.org/openid/connect/issues/1511/determining-if-an-rp-is-a-member-of-a
https://bitbucket.org/openid/connect/issues/1482/static-trust-negotiation-in-a-scenario

even if we talk of thsi in oidc fed we may consider that the concept of trust marks is moving to user centric and eIDAS2 approaches and it would be interesting developing it (in all the sauces) in oidc fed before reusing this in many other contexts.

Eg

trust_marks_hint=[ ... the list of trust marks ...]

In the oidc fed specs we may only consider to have this paramenter in the request object as OPTIONAL.

[Giuseppe De Marco]

we know that a kernel has two tcp queues, the conn and its backlog (with limits).
for each http request the OP will trigger a new connection, this means that 1 slot is taken by the ingoing http request and another slot by the outgoing request. This reduces the tcp queue.

Driving an attack over a OIDC Federation would be advantaged by this behaviour. With a botnet an attacker would forge thousands of fake authz request and each of them will produce an amplification of x2 to the OPs.

Using trust_mark_hints we can avoid this, moving the static validation of trust mark inside the authz request, first of the fetch of the entity configuration

[Michael Jones]

Giuseppe to create a PR for us to evaluate.

[Giuseppe De Marco]

As discussed with @Roland Hedberg we have a good consideration of https://bitbucket.org/openid/connect/issues/1533/federation-trust-path-hint-in-the-authz and a new proposal for this trust_marks_hint.

if trust_path_hints helps the metadata discovery process, making it more efficient with this simple hint, we may abadon the hints of the trust marks replacing these with a new parameter, called entity_configuration or similar, that pushes the entire statement (signed JWT) in the authz request object.

Well this requires PAR.

assumptions
- it doens’t replace the openid-federation that’s always available to the well known web path

pros:
- avoids the fetch of the openid-federation to an OP, reduces the metadata discovery (a single http request less). Removes completely the trigger of at least one new foreign http connection from the OP to the RP.

cons:
- PAR is required (it would had been the same with trust_mark_hints)

‌

[Michael Jones]

@John Bradley summarized during the 9-Aug-22 Federation editor’s call that this would provide the entity statement up front, rather than having to fetch it. This could help mitigate some denial of service attacks. @Giuseppe De Marco will write a PR.

[Giuseppe De Marco]

I’d close this issue in favor of this one
https://bitbucket.org/openid/connect/issues/1594/federation-trust-chain-in-authz-request

[Michael Jones]

Duplicate of #1594.