[Resolve Entity Endpoint] dynamic propagation of metadata renewal

[Giuseppe De Marco]

Taking up the above here with the extension of the Endpoint Resolve Statement.

Requirement
Equip OIDC Federation-based infrastructures with a mechanism to update metadata from and to all the parties, in real time.

Solution
The Resolve Statement Endpoint may optionally enable a POST method, protected by private_key_jwt or any other client authentication as necessary requirement.

The client authentication protects the trigger of a new Trust Chain evaluation, for a given subject and a given trust anchor, to the Resolve endpoint.

When a leaf updates its Entity Configuration it may requests to its superiors (authority_hints) to update the Trust Chain related to itself.

The superior that receives this request, authenticates the client (eg: private_key_jwt) and triggers a renewal of the Trust chain for the given subject. This obtain the final metadata and the trust marks of the requestor, and consequently updates the result of the entity statement resolve response, relative to the descendant subject.

The leaf should execute this call to all corresponding superiors identified on the path to one or more trust anchors.

This would result in the Trust Anchor getting the final metadata and trust marks valid for each leaf, even if the leaf is not one of its direct descendant. As a result, the Entity Resolve endpoint responses will always be up to date. A participant in a federation could trigger an update to all the federation resolve endpoints as well, exposed by third-party systems, at any occurrence.

Result and benefits
1. All the leafs in a federation could updates their entity configurations without incurring problems of temporary misalignment.
2. In the case that all the entities exposes the resolve entity endpoint with the POST method here proposed, a RP that got evidence of the misalignment of its metadata to a OP could trigger a new trust chain processing, relate to itself, to the OP.

Security considerations

The private_key_jwt should have an expiration time in seconds, not exceeding a time limit, to reduce the danger that the theft of this could somehow become a vehicle of a propagation attack by triggering trust chain validation to and from many parts. The cache duration of a Resolve entity endpoint HTTP POST response, related to a leaf and a trust anchor, must be equal in seconds to the difference of the exp - iat values, contained in the private_key_jwt. This prevents that a JWT used in a private_key_jwt could be replayed over and over to the same endpoint and be veicle of a resource consumption attack (if the claim jti may be absent for some reason). This would cause a leaf that needs frequent updates to configure the exp value of private_key_jwt as low as possible, making the cache lifetime short.

rate limiting and throttling: see https://bitbucket.org/openid/connect/issues/1416/security-considerations-for-federation-api

the question is whether to allow only descendants to trigger this call, and then delegate the superiors to the trigger at their superiors or consider this proposal as it is.

[Giuseppe De Marco]

the alternatives that I have identified are:

1. the leaf makes all the calls to all the superiors up to the trust anchor
2. the leaf makes the call only to its immediate superiors and these in turn up to the trust anchors
3. the leaf makes the call to the trust anchor and this to all intermediaries identified in the path towards this

‌

[Giuseppe De Marco]

this is an implementation topic more then a requirement in the specs, anyway I would be interested to introduce in OIDC Fed two modes of Resolve endpoint:

GET -> anon request, treturn metadata/trust marks as they are in the cache if available, otherwise 404
POST -> private_key_jwt, triggers/renews the trust chain and return fresh metadata/trust marks

[Vladimir Dzhuvinov]

Do I understand correctly that the idea behind this process is to prevent stale registrations?

When we implemented OIDC Federation (v12) we understood stale client metadata can become a problem for OPs.

[Giuseppe De Marco]

@Vladimir Dzhuvinov It is a great pleasure for me to talk to an OIDC Fed implementor like you.

What you say is accurate, the problem is that OIDC Federation partially solves the the freshness of third-party metadata at each participant.

As it stands, we can identify in OIDC Fed a strategy that we have defined in the regulations of our implementations within good practices as well. This considers that the Trust Anchor keeps the exp of the trust chain relatively low (not more than 24 hours) and suggests to all the participants to "add" the new definitions (redirect_uris, jwks, contacts ...) rather than replace/overwrite the previous ones. After 24 hours each participant can remove the old definitions and use the new one in the OIDC core ops, having the certainty that all parties have renewed the trust chain. In this aspect the resolve entity statement offers an appropriate feedback that allows a verification of the past updates of trust chain (think of a RP that has added a redirect_uri and wants to verify its new metadata at each OP before removing the old definitions).

In Italy we have decided to regulate the presence of resolve entity statements at all endpoints, even at the leaves, for one simple reason: transparency. We want to put all parts in a position to diagnose misalignment issues. We believe this is an innovative feature compared to the pre-existing infrastructure based on SAML2 and we were able to think so thanks to the Federation API that OIDC Fed proposes.

At this update strategy some analyst teams propose to introduce in the federation API a signal system, to trigger updates of trust chains when necessary.

For this reason we have defined that:

1. resolve entity statement in GET must reuse only trust chains already cached AND NOT trigger new ones (to avoid propagation attacks triggered by anonimous requesters)
2. resolve entity statement response SHOULD also display in its claims the verifiable trust chain to raise the level of assurance of its processing (see https://bitbucket.org/openid/connect/issues/1489/federation-resolve-entity-endpoint-feat)
3. resolve entity statement MAY allow, through the POST method and a client authentication (private_key_jwt) the triggering of any trust chain for a specific entity. This feature must be protected with a client authentication to avoid abuse by compromised nodes (daily rates of up to 5 triggers per day, for example, and a cache as described above).

We are therefore interested in defining both the claim trust_chain and the POST method within the OIDC Fed specification for the resolve entity endpoint.

The current specification does not define if resolve endpoint should or can trigger a new trust chain for an entity. This leaves the implementors at risk of introducing propagation attacks resulting from the abuse of this.

In a PR, we would first like to point out to the implementors that GET requests MUST NOT trigger new trust chains and that if this endpoint exposes a resource through POST this MUST be protected by client authentication and trigger a data trust chain subject (also different from the applicant).

‌

[Roland Hedberg]

A signalling system like the one you propose has by design been left out of the specification. There are several ways of doing this and we felt that we could not mandate the use of a specific solution. Personally I’d probably use something like Websub (https://en.wikipedia.org/wiki/WebSub) for this instead of inventing something new.

[Nat Sakimura]

Giusppe felt Roland's comment is reasonable. He will check back to his implementers.

[Giuseppe De Marco]

WebSub is a great solution, however and unfortunately several collegues have pointed out to me that it is deprecable.

This issue considers two fundamental elements:

1. resolve endpoint is not protected and does not trigger a trust chain calculation but returns previously calculated trust chain (that’s a security requiremets to avoid propagation attacks)
2. resolve endpoint if protected could trigger new trust chains

Considering the point two: we considered the possibility to exploit resolve endpoint to trigger a trust chain update to any party that exposes it. This consideration came naturally to us because within our implementations and at the regulatory level of federation (two federations actually) we have indicated the resolve endpoint as mandatory. For this reason we decided to use it also for a signalling system.

this does not preclude the possibility, or necessity, of developing an ad-hoc federation endpoint to trigger this type of upgrade.

Let me give an example

an endpoint, protected, that takes as argument both the sub of the entity that reports to be updated and the trust anchor for which it wants to be resolved (exactly like for the resolve endpoint). A partecipant updates its oidc core metadata, then triggers the update to all the known parties. An OP, for example, triggers to all the known RP and viceversa

[Giuseppe De Marco]

We may consider this additional feature completely out of the scopes of the specs. Having said this, I think that the implementers could adopt their own solutions or something that uses oidc shared signals.

We’ll have updates on this when time will permit

[Michael Jones]

Placing on hold, per @Giuseppe De Marco 's suggestion during discussions including @Roland Hedberg during TNC.