Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Comments and questions, particularly around the use of ‘Mutual TLS’ #60

Open
WestpacOpenBanking opened this issue Mar 10, 2019 · 0 comments
Assignees

Comments

@WestpacOpenBanking
Copy link

Mutual TLS

The draft security standard uses the term ‘Mutual TLS’ ambiguously. In some contexts it appears that MTLS is meant, and in other cases it appears that the standard may have intended TLS Mutually Authenticated (i.e. requiring the client to prove its identity with a certificate as in RFC5246 7.4.6).

We suggest either removing the term in all cases, or aligning with the [MTLS] normative reference which uses this term to mean Transport Layer Security Mutual Authentication (TLS-MA). If the latter option is taken then the definition of Mutual TLS should be made explicit.

Comments and Questions

Partially related to the above, we have the following comments and questions:

Part(s) of standard Comment/Question
Where references are made to ‘MTLS’ What validation checks are needed on the client certificates for resource servers and for authorisation servers?   Is validation of the certificate chain from the trusted CA (i.e. the ACCC directory) or any other validation check required? Our expectation is that this is not the case as in the [MTLS] normative reference s.2 and s4.2.
11.2. Mutual TLS
which is referenced by
5. Client Authentication

From 11.2 “All back-channel communication between Data Recipient and Data Holder systems MUST incorporate, unless stated otherwise, MTLS as part of the TLS handshake…”   Similarly in 5.
Is TLS-MA meant here?

i.e. “TLS-MA as part of the TLS handshake…”
11.2. Mutual TLS

“The presented Server transport certificate MUST be issued by the CDR Certificate Authority (CA). The Client MUST NOT trust Server transport certificates issued by other authorities.”
What is the rationale for requiring server certificates to be bound to the CDR (ACCC) certificate authority? Why not allow other certificate authorities already trusted by industry (e.g. Entrust, DigitCert)?
11.2. Mutual TLS (This question may be best directed to the ACCC.)
Will client certificates be bound in any way to the client applications of data consumers in any way? I.e. If a data consumer has two client applications will there be a client certificate issued for each or a common certificate for both?
13. Endpoints This section gives transport security requirements for each authorisation endpoint as either ‘TLS’ or ‘MTLS’.

Specific references as to what needs to be enforced in the MTLS case would be appreciated. Do both cases require TLS-MA? Does ‘TLS’ mean ‘TLS-MA’?

What about resource endpoints? Should we follow the standards draft for the requirements? It would be good to align the formatting between the two if so. Is ‘Mutual TLS’ referring to TLS-MA in the Additional Constraints section we linked to above? We will also direct this question to the standards working group.

Interpretation of the security profile

Across the security profile and the technical standard, we’d like to confirm our interpretations. In particular:

  • The following authorisation endpoints are TLS only:
    • Authorisation Endpoint
    • OpenID Provider Configuration Endpoint
    • JWKS Endpoint
  • The following authorisation endpoints are TLS with signed JWT using a ACCC client certificate which is not required to be validated during the TLS handshake:
    • Backchannel Authorisation Endpoint
    • Token Endpoint
    • Userinfo Endpoint
    • Introspection Endpoint
    • Revocation Endpoint
    • Client Registration Endpoint
  • The resource endpoints are TLS-MA using a ACCC issued client certificate which should be validated and that there is no other alternative method supported (e.g. TLS with a signed JWT using a client certificate).

URI Structure

The draft technical standard specifies a <provider path> for resource endpoints. We suggest that explicit requirements are also published for the endpoints in the security standard. We request that the following assumptions are accommodated:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants