Trust Anchor Mix-Up (Federation Integrity Property)

[SECtim]

Consider the following excerpt from the example of two Federations rooted at two different Trust Anchors as given in Section 1:

.-----------------.            .-----------------.
|  Trust Anchor A |            |  Trust Anchor B |
'------.--.-------'            '----.--.--.------'
       |  |                         |  |
    .--'  '---. .-------------------'  |
    |         | |                      |
.---v.  .-----v-v------.   .-----------'
|    |  | Intermediate |   |
'----'  '--.--.--.-----'   |
           |  |  |         |
   .-------'  |  '------.  |
   |          |         |  |
.--v-.      .-v--.     .v--v.
| RP |      |    |     | OP |
'----'      '----'     '----'

Now, suppose that RP only trusts Trust Anchor A, whereas OP only trusts Trust Anchor B.
A user of RP requests to authenticate with OP, so RP initiates an automatic registration with OP (Section 12.1):

1. RP uses the process defined in Section 10 to learn OP's metadata, i.e., fetches OP's Entity Configuration and then resolving a Trust Chain, starting with OP's authority_hints (i.e., Intermediate and B). Following the Intermediate path, RP assembles a Trust Chain from OP to A, i.e., the chain [OP, Intermediate, A].
2. RP validates that Trust Chain and uses it to resolve OP's openid_provider metadata, in particular, its authorization endpoint.
3. RP sends an authentication request with a signed request object (that does not contain a Trust Chain) to OP's authentication endpoint.
4. OP processes this request as described in Section 12.1.1. I.e., among other things, OP fetches RP's Entity Configuration and, starting with RP's authority_hints, resolves a Trust Chain, say [RP, Intermediate, B].
5. OP validates that Trust Chain and uses it to resolve RP's openid_relying_party metadata, which OP then uses to automatically register RP.

I.e., both OP and RP "trust" each other without having a Trust Anchor in common (actually, RP "trusts" OP already in Step 3).

Unless we overlooked something, the Federation specification does not prevent this from happening.

Note: Such a situation may also lead to disagreement on the openid_... metadata if the different Trust Anchors employ different Federation Policies.

[SECtim]

After thinking about it for a bit, @PedramHD and I think that a possible solution to this might be the following:

• In its Entity Configuration, each Federation Entity publishes a list of Trust Anchor Entity IDs that it trusts (either directly, or via some URI, similar to jwks).
• During Trust Chain resolution (Section 10.1), the Entity that is currently constructing a Trust Chain for some subject only accepts Trust Chains that end in one of the Trust Anchors included in sub's Entity Configuration (and of course, the Entity that is constructing the Trust Chain must also trust that Trust Anchor, but that is already the case in the current spec).

However, we note that there still is the issue described in #86; the above changes only make sure that both Entities are part of at least one shared Federation and that the Trust Chain used to resolve the other Entity's metadata ends in one of the shared Trust Anchors.

[peppelinux]

I.e., both OP and RP "trust" each other without having a Trust Anchor in common (actually, RP "trusts" OP already in Step 3).

this was the impl profile got in OpenID GAIN PoC WG, allowing a more "decentralized" approach with multiple Trust Anchors and not all the participants be part of all the federations/network bound to each trust anchor.

The decision of enabling or not this approach depends by the trust framework, where implementation allowing this promiscuity it is technically possible.

I (leaf) live in my palace (federation) and follow my palace's rules.
I go to a friends' dinner, in another palace, applying their rules.

It depends to me decide if I can do this or not, if I must trust only the entities that applies my same policies or if I can apply also other policies of Trust Anchors I trust without being part of their network.

[SECtim]

The decision of enabling or not this approach depends by the trust framework, where implementation allowing this promiscuity it is technically possible.

For Federation, the trust model seems to be such that two Entities trust each other if they are part of the same Federation, i.e., have trust in the same Trust Anchor. E.g., the abstract says:

An Entity in the federation must be able to trust that other Entities it interacts with belong to the same federation.

and in section 1:

This specification describes how two Entities that would like to interact can establish trust between them by means of a trusted third party called a Trust Anchor.

... which implies that there are two Entities and one Trust Anchor (otherwise, the Trust Anchor would not just be "a [...] third party"). Also in section 1:

Determining that two Entities belong to the same federation is the basis for establishing trust between them in this specification. [...] Every Entity is able to establish mutual trust with any other Entity by means of having at least one common Trust Anchor between them.

Section 12.2.1 also hints at this:

Once the RP has determined a set of Trust Anchors it has in common with the OP, it chooses the subset it wants to proceed with.

So I think that for Federation, the described scenario should not be possible (unless the trust model description all over the spec is very misleading, in which case it should be clarified).

[peppelinux]

Trust Model is related to the model only, that uses a trusted third party (Trust Anchor)

There might be more than a single Trust Anchor

according to the specs, all the entities must be linked at least to a superior entity, no matters if it is the trust anchor or its intermediate

an intermediate can be linked to one or more intermediates or trust anchors

therefore the leaf might not known how many trust anchors it is linked to, through each intermediate above it

it's up to who evaluates the trust decide which trust anchor to use.

This is the fit we havei n the current specs.

Other implementation profiles, such that obtained in OpenID GAIN POC WG, introduced a more flexible approach, as I described above. Not necessarly all the participants might found themseleves under the same trust anchor.

entity A can trust trust anchor B without be linked to it, therefore it can build a trust chain about entity B, under trust anchor B, applying trust anchor B policies and apply them.

[SECtim]

Trust Model is related to the model only, that uses a trusted third party (Trust Anchor)

... which is the model that the Federation spec says it uses (in section 1, as cited above), or am I completely misreading that section?

---

Assuming that my understanding of section 1 is indeed incorrect, what you're saying is: Entities A and B "being in the same Federation F" does NOT mean that there is a Trust Anchor (at the root of F) that is trusted by both, A and B?
Then, what DOES it mean for A and B to be in the same Federation F? Or even: What does it mean for a given Entity A to be in a Federation F? What defines a Federation F if not the (single) Trust Anchor it is rooted in?
Wouldn't that also imply that an Entity has no way of explicitly choosing which Federations it participates in?

In any case, if what you're describing is indeed the trust model underlying Federation, then I think this should be made much more explicit throughout the specification, see, e.g., the things I cited in my comment above.

[cicnavi]

Since both RP and OP will have to resolve the trust chain during registration / authentication, I don't see a problem of "not being sure in which federation we are". The entity which tries to resolve the trust chain defines which trust anchor(s) is/are to be used, and this is actually visible in the description of the resolve endopint: https://openid.net/specs/openid-federation-1_0.html#name-resolve-entity.

However, are there any drawbacks in having "valid trust anchors" listed in (leaf) entity configurations? My first though on this is that it is a good idea, however not sure about the broader implications.

So in example above, both RP and OP know who their own trusted anchors are. When an RP tries to resolve trust chain for OP, if "valid trust anchors" were listed in OP entity configuration, RP could "fail early" during trust chain resolution if RP sees that the TA that RP trusts is not in the OP list of valid trust anchors.

[SECtim]

Since both RP and OP will have to resolve the trust chain during registration / authentication, I don't see a problem of "not being sure in which federation we are".

Whether this is a problem or not depends on the targeted trust model - if mutual trust is supposed to mean "we are in at least one common Federation", then the scenario described above is a problem. If mutual trust only means "we both have some valid Trust Chain from the other Entity to one of our own Trust Anchors", then this is indeed fine.

I might add: From my point of view, the trust model can be either way - but I think the specification should be very explicit about which trust model it uses. And with the current texts I cited above, my understanding of the Federation spec is such that the targeted trust model revolves around "being in the same Federation" and "having at least one common Trust Anchor between" Entities.

I think that @cicnavi's comment also implies this understanding:

[...] RP could "fail early" during trust chain resolution if RP sees that the TA that RP trusts is not in the OP list of valid trust anchors.

This only makes sense if the underlying assumption is that RP and OP must have at least one common Trust Anchor.

[cicnavi]

[...] RP could "fail early" during trust chain resolution if RP sees that the TA that RP trusts is not in the OP list of valid trust anchors.

This only makes sense if the underlying assumption is that RP and OP must have at least one common Trust Anchor.

Oh right, that would actually disable your example from happening!

[jcmelati]

whereas OP only trusts Trust Anchor B

If OP only trusts Trust Anchor B, wouldn't that mean that the initial diagram is not correct, because then OP would not have Intermediate as an Authority Hint?

[SECtim]

@jcmelati The trust model of Federation (according to the spec text) revolves around trust in Trust Anchors, not Intermediates. Of course, OPs authority hints in the example would contain Intermediate and B (see also the initial issue description).

[jcmelati]

@SECtim From my current understanding, it is up for the one that is evaluating trust (RP) to define which Trust Anchor to be used. While you can set up a whole Federation structure, its effects only take shape when RP is trying to establish trust from it's perspective. Saying OP only trusts Trust Anchor B overlooks the dynamic nature of trust chains when OP also defines Intermediate as a direct superior.

According to the spec, trust is not limited to be defined by a Trust Anchor special type of Entity but rather encompasses the possibility of intermediates acting as trust anchors depending on the specific federation and context.

From the spec: While Trust Anchors typically have no Superiors, a Trust Anchor will have a Superior when the Trust Anchor also acts as an Intermediate Entity in another federation.

In the first diagram, what is described as Intermediate (and also all other entities) can only be described so in relation to a Trust Anchor context. In some other hypothetical use case for some other RP, Intermediate can very well be a Trust Anchor. In both cases, it is up to the verifier to establish the Trust Anchor context that it expects to make a decision about trusting or not some federated Entity.

[SECtim]

From my current understanding, it is up for the one that is evaluating trust (RP) to define which Trust Anchor to be used.

Agreed, and the initial example is in line with this.

Saying OP only trusts Trust Anchor B overlooks the dynamic nature of trust chains when OP also defines Intermediate as a direct superior.

I don't think the spec in its current form supports this statement. In particular, intermediates are explicitly mentioned as such (and as part of the immediate superiors of an Entity), separate from mentions of Trust Anchors (of course, an intermediate MAY at the same time act as a Trust Anchor). Also, what makes a Trust Anchor A a Trust Anchor? I'd argue: Some Entity has A's Entity ID and public keys configured as their Trust Anchor (see section 10: "An Entity
that wants to establish trust with another Entity MUST have Party B's Entity Identifier and a list of Entity Identifiers of Trust Anchors and their public signing keys.")
Hence, if in the example neither OP, nor RP have Intermediate in their respective Trust Anchor lists, then Intermediate is not a trust anchor - in any case, if the word "trust" (and its rather fuzzy meaning) bothers you in the context of Trust Anchor/any Entity, we can just replace it with "is part of Entity's list of Trust Anchors". In the context of "RP trusts OP" and vice-versa, the example above just uses the wording from the spec (Section 1).

According to the spec, trust is not limited to be defined by a Trust Anchor special type of Entity but rather encompasses the possibility of intermediates acting as trust anchors depending on the specific federation and context.

Also agreed, but that is not the case in the initial example, Intermediate really IS an Intermediate, not a "hidden" Trust Anchor.

In the first diagram, what is described as Intermediate (and also all other entities) can only be described so in relation to a Trust Anchor context. In some other hypothetical use case for some other RP, Intermediate can very well be a Trust Anchor. In both cases, it is up to the verifier to establish the Trust Anchor context that it expects to make a decision about trusting or not some federated Entity.

True, but again: In the initial example, Intermediate is not a Trust Anchor, it is just an Intermediate.

[rohe]

@SECtim My take on this has from the beginning been that two entities can trust each other's metadata/trust marks/keys if they are in the same federation.

The GAIN POC model is in my mind a bastard and can create any number of problems.

Since every entity in the federation MUST know at any point in time what TAs it trusts, publishing this list in the EC may actually work. It can not publish all the TAs you may end up at if you follow all possible trust chains that starts with the entity but that is not a problem.
We've had this discussion a number of times and I have previously pushed back just because the entity would not know its list of trusted TAs but in fact it must.

Still this doesn't solve the problem completely. If we both trust TAs A and B and we do automatic registration then you and I may use different TAs when we collect the trust chains. I have no idea how to remedy this since there is no way to communicate the choice to the opponent.

[cicnavi]

Was some sort of "trust anchor signaling" ever considered? From the top of my head - what about introduction of additional parameter when fetching Entity Configurations that would signal the intended Trust Anchor. It seems that Well-known URIs does not prohibit this:

Registrations MAY also contain additional information, such as the
syntax of additional path components, query strings, and/or fragment
identifiers to be appended to the well-known URI, or protocol-
specific details (e.g., HTTP [RFC7231] method handling).

When resolving Trust Chain, since we have to fetch Entity Configurations for authority hints, if we also send "Trust Anchor Signal" to them, I guess in the end we would get to one "truly common" Trust Anchor. Not sure if "Trust Anchor Signal" would be necessary on fetch endpoint...

For Automatic Registration by using request object directly, I see that for example RP can already signal the OP the "desired" Trust Anchor by including the 'trust_chain' claim.

trust_chain
OPTIONAL. Array containing the sequence of Entity Statements that comprise the Trust Chain between the RP making the request and the selected Trust Anchor, sorted as in Section 4. When the RP and the OP are part of the same federation, the RP MUST select a Trust Anchor that it has in common with the OP; otherwise, the RP is free to select the Trust Anchor to use.

So, for the scenario in which RP first does Trust Chain resolution for OP by signaling the desired TA, and then sends a hint of the desired TA in the 'trust_chain' claim when doing (automatic) registration, I guess the one common TA would be known / things would be clear. Again, I don't know what other implications all this has...