- edited description
[Federation] tls_client_auth as a request authentication method
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.
Comments (11)
-
reporter -
reporter - edited description
-
- changed status to open
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.
-
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
andtls_client_auth_san_*
for thetls_client_auth
client authentication method. To achieve this I would use a bulleted list, listing all the possibletls_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
-
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?
-
-
assigned issue to
-
assigned issue to
-
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.
-
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.
-
- changed milestone to Implementer's Draft
-
To be fixed by https://bitbucket.org/openid/connect/pull-requests/714
-
- changed status to resolved
- Log in to comment