Use of FAPI with mandatory MTLS

[bitbucket-import-issues]

Originally submitted by josephheenan (Joseph Heenan) on 2024-01-13

We are continuing to see ecosystems that adopt FAPI but also mandate the use of MTLS on all endpoints.

Certainly in FAPI1 we have seen this with ConnectID, Brazil, UK and CDR - i.e. all the ecosystems we have certification tests for, but we also have indications that other ecosystems might adopt similar approaches.

If MTLS sender constrained access tokens are used (which is the only option in FAPI1 and I think still a common choice in FAPI2) this potentially only affects a few endpoints:

1. Discovery
2. Server JWKS
3. PAR

Several ecosystems mandate the use of MTLS even when using private_key_jwt. I think it is a ‘Defence in depth’ type approach, with many security teams having a preference for enforcing MTLS at the perimeter but traffic within the perimeter still having some protection (i.e. the client authentication assertion).

The fact that all ecosystems and the main spec diverge in this area is one of the reasons we end up having to create ecosystem specific certification test variants. I think we should discuss it in the WG and consider whether this kind of setup should be included as an option in the specs & certification tests.

‌

(We did sort of discuss this a little bit here: https://bitbucket.org/openid/fapi/issues/493/certification-query-supply-of-tls-client )

---

Bitbucket status: resolved

Bitbucket origin: issue 670

[bitbucket-import-issues]

Originally submitted by Ralph Bragg (Ralph Bragg) on 2024-01-13

I would really welcome a discussion on this point. We are this time and time again with PAR especially.

‌

[bitbucket-import-issues]

Originally submitted by panva (Filip Skokan) on 2024-01-13

We are this time and time again with PAR especially.

If only ecosystems stopped laying down landmines in their own fields. If these require use of mtls everywhere then they should also prohibit the use of AS mtls_endpoint_aliases.

[bitbucket-import-issues]

Originally submitted by panva (Filip Skokan) on 2024-01-16

To my previous point, FAPI 2.0 Security Profile already has a section this kind of setup that accounts for endpoints that may end up in a state where the client has no reason to select an mtls endpoint alias but one may be provided on the http client layer.

… however in the interests of interoperability this document state that when using TLS as a transport level protection in this manner, authorization servers should expect clients to call the endpoints located in the root of the server metadata, and not those found in mtls_endpoint_aliases.

Joseph Heenan Are you saying that ecosystem specific plans exist solely because of this MTLS-everywhere (but not really everywhere [or even discovery, jwks]?) requirement?

[bitbucket-import-issues]

Originally submitted by josephheenan (Joseph Heenan) on 2024-01-16

Joseph Heenan Are you saying that ecosystem specific plans exist solely because of this MTLS-everywhere (but not really everywhere [or even discovery, jwks]?) requirement?

It is not the only reason we currently have profiles, but some/most of the other reasons the WG has been trying to solve with e.g. the grant management spec to replace custom pre-lodged intent / consent management APIs.

‌

‌

[bitbucket-import-issues]

Originally submitted by panva (Filip Skokan) on 2024-01-16

So with the existing language in place, what do you believe is missing?

[bitbucket-import-issues]

Originally submitted by panva (Filip Skokan) on 2024-01-16

FYI today’s conformance suite behaviour allows non-profiled FAPI 2.0 PAR requests with private_key_jwt auth to target either of the exposed endpoints (mtls and non-mtls). That in itself creates a scenario in which certified AS/client may not be able to interoperate if the AS’s mtls endpoints are set up to reject requests that have no reason to use an alias but the client wrongly chooses to use an aliased PAR endpoint.

[bitbucket-import-issues]

Originally submitted by josephheenan (Joseph Heenan) on 2024-01-17

FYI today’s conformance suite behaviour allows non-profiled FAPI 2.0 PAR requests with private_key_jwt auth to target either of the exposed endpoints (mtls and non-mtls). That in itself creates a scenario in which certified AS/client may not be able to interoperate if the AS’s mtls endpoints are set up to reject requests that have no reason to use an alias but the client wrongly chooses to use an aliased PAR endpoint.

Thanks! Tracking that as a bug here:

https://gitlab.com/openid/conformance-suite/-/issues/1299

‌

[bitbucket-import-issues]

Originally submitted by josephheenan (Joseph Heenan) on 2024-01-17

So with the existing language in place, what do you believe is missing?

I think perhaps the minimum I am looking for is the working group to make a decision on is, if an MTLS certificate is included in the test configuration, is it acceptable for the conformance suite to just try to present it at all endpoints even when testing ‘generic FAPI’.

If it isn’t, then a decision on whether we should create an “mtls always” (better names gratefully accepted) certification profile or not.

What if anything we mention in the spec probably depends on the answers to those questions.

[bitbucket-import-issues]

Originally submitted by panva (Filip Skokan) on 2024-01-17

is it acceptable for the conformance suite to just try to present it at all endpoints even when testing ‘generic FAPI’.

It is not, as evident by the PAR endpoint interactions when configured with mtls cert just for sender constraining, not client auth.

If it isn’t, then a decision on whether we should create an “mtls always” (better names gratefully accepted) certification profile or not.

What, if anything, would such profile achieve for the ecosystems? Such configuration/expectation is already part of the ecosystem specific profiles that, at least for now, have other reasons to exist. If this is to be refactored in the suite to be a true “variant” (in the sense that the conformance software has) that has a preconfigured value for the existing non-ecosystem profiles(false) is in my opinion at the certification team’s own discretion.

I would recommend not to expand the non-ecosystem profile list with such an option. Between SP and MS there’s already 16, adding another variant would make that 32 (and i’m only counting MS with both JARM and JAR, not on/off combinations thereof, and that’s without any support for HTTP Message Signatures :head_bandage: ).

[bitbucket-import-issues]

Originally submitted by josephheenan (Joseph Heenan) on 2024-01-17

What, if anything, would such profile achieve for the ecosystems?

The certification team have had a clear direction from various parts of OpenID Foundation including the FAPI working group that certification tests should not be ecosystem specific if at all possible as creating versions of the tests for every ecosystem that adopts FAPI is not scalable.

If the FAPI working group are not going to do something about this ticket, there is no way I can achieve that goal.