[Federation] tls_client_auth as a request authentication method

[Takahiko Kawasaki]

10.1.1.2.1. Processing the Authentication Request of the OpenID Federation specifcation says as follows with regard to tls_client_auth:

tls_client_auth

If mTLS is used and the certificate used was not self-signed, then the Subject Alternative Name of the certificate MUST match the Entity Identifier of the RP.

‌

This requirement consequently requires that the RP have the tls_client_auth_san_uri metadata whose value matches the entity identifier of the RP, and the client certificate be created so. Having the tls_client_auth_san_uri metadata excludes the other tls_client_auth_ metadata such as tls_client_auth_subject_dn, tls_client_auth_san_dns, tls_client_auth_san_ip and tls_client_auth_san_email. (cf. RFC 8705, 2.1.2. Client Registration Metadata)

This restriction can not coexist with some real-world ecosystems. For example, Open Finance in Brazil prohibits client metadata from including tls_client_auth_san_* in the context of Dynamic Client Registration (unless the rule has changed since I read their specification in the past). (cf. “Implementer’s note about Open Banking Brasil“)

I feel that it is better to remove the requirement “the Subject Alternative Name of the certificate MUST match the Entity Identifier of the RP” so that the RP can use any of tls_client_auth_subject_dn and tls_client_auth_san_* for the tls_client_auth client authentication method.

[Michael Jones]

We discussed this on the 13-Nov-23 working group call. It seems that experts in TLS client authentication will need to look at this.

[Giuseppe De Marco]

It seems to me that it makes sense removing the text that says: “the Subject Alternative Name of the certificate MUST match the Entity Identifier of the RP”, so that the RP can use any of tls_client_auth_subject_dn and tls_client_auth_san_* for the tls_client_auth client authentication method. To achieve this I would use a bulleted list, listing all the possible tls_client_ metadata.

at the same time giving this freedom to the RP may introduce greater complexity into implementations and consequent security issues.

We await further feedback from implementers

[Michael Jones]

It could be useful to compare the requirements in https://www.rfc-editor.org/rfc/rfc8705.html (OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens) with these. @ve7jtb - could you comment on this?

[Michael Jones]

I believe that we need to be clearer about how the client is verified when mTLS is used. https://bitbucket.org/openid/connect/pull-requests/678 tightens this for signature-based verification methods but we need to discuss what to say about mTLS methods.

[John Bradley]

The wording for both tls_client auth methods is not ideal. This needs to apply to the meta-data of both Connect RP and Oauth clients. For self signed the certificate needs to match one in the JWKS or JWKS_URI that has a use value of sig.

For tls_client_auth exactly one of the 4 members specified in Section 2.1.2 of RFC8705 needs to be present in the metadata to indicate the subject value of the certificate that the server is to expect when authenticating the respective client.

[Michael Jones]

To be fixed by https://bitbucket.org/openid/connect/pull-requests/714

[Michael Jones]

Fixed by https://bitbucket.org/openid/connect/pull-requests/714