Removal of requirement for CDR CA Certificate for JWKS and Discovery end points

[CDR-API-Stream]

Description

There has been a request from a number of participants in the phase 2 implementation that the requirement for security end points marked as requiring TLS to modify the standards to allow any Root CA to be used for TLS on these end points.

Area Affected

The change would impact the security end points section of the standards.

Change Proposed

Based on conversations amongst the implementation participants there are two options that have been raised:

1. Revert the affected data holder end points back to MTLS (ie. reverse the previous change for data holders)
2. Allow any CA Root to be used for security end points using TLS

There has been some discussion on this topic already on the following issues:

• 43 (one of the original requests for change)

• 40 (another original request for change)

• 69 (a related request for clarification)

• https://github.com/ConsumerDataStandardsAustralia/standards/issues/65 (contains a discussion on attack vectors for ADRs with many CA Roots installed in their trust store)

Note: The DSB will not consider this change for the phase 2 implementation timeframes unless:

1. There is a request from the ACCC for this to be an urgent change
2. The Participant holders explicitly confirm that they do not consider the vector described in the discussion in https://github.com/ConsumerDataStandardsAustralia/standards/issues/65 is of significant risk

[perlboy]

The comments I provided (both as @perlboy and @csirostu) in ConsumerDataStandardsAustralia/standards#65 are specific statements with respect to unauthenticated endpoints delivering unsigned payloads.

The application of this unrelated discussion involving signed payloads (or data which is verified via a third-party, such as ACCC as part of the SSA generation) is invalid. If anything the application of CDR CA for JWKS and Discovery endpoints represents an inconsistent approach taken by the DSB to principles around securing trust chains. It also adds no additional tamper protection so the benefit of this approach is unclear. There are thousands of OIDC deployments online and in use which do not use any type of custom CA for these endpoints so there appears little value provided.

As indicated in the linked thread recipients, primarily as a consequence of allowing Global CA's at all, will likely resolve to rely upon a systems default keystore (Global CA) so the benefit of requiring ACCC CA (which is an intermediary CA to a Global CA) verification within client operations on anything is significantly diminished and possibly entirely absent.

I have tried numerous times to articulate the implications of this approach but it would appear that the DSB continues to lack an understanding of how public key cryptography works and how it is applied in a development context. I see no value in personally continuing to try and explain public key cryptography.

[CDR-API-Stream]

To be clear, the specific attack vector that is of concern and for which comment is sought is as follows:

• An ADR implements a server side implementation to access the authorisation server of a data holder in accordance with the standards
• In their trust store a wide list of CAs are loaded along with the CDR CA so that the JWKS end point and OIDC discovery end point can be accessed alongside the other authorisation server end points
• A malicious actor succeeds in redirecting a data recipient to a fake OIDC discovery end point and JWKS end point possibly through DNS poisoning or modification of the InfoSec base URI through social engineering
• The substituted end points would utilise a valid certificate from a global CA which would be validated by the data recipient trust store containing the wide list of valid CAs
• The malicious actor provides the data recipient with OIDC discovery information and keys that allow for a fake authorisation server to proxy requests to, and responses from, the real authorisation server
• The fake AS would utilise a valid certificate from a global CA which would be validated by the data recipient trust store containing the wide list of valid CAs
• The fake AS, with access to the real keys for both data recipient and data holder would then be able to access the responses the token end point containing active access and refresh tokens

It is based on this (or similar) attack vector that the exclusive use of the CDR CA for access to the authorisation server end points was maintained.

For this situation to be changed the DSB would require clear guidance from the participants, especially data holders, that the scenario described above is not considered a significant risk.

[RalphBragg]

Hi,

Realise i haven't piped up in a while.

As I understand it, this ticket is trying to come up with a solution that ensures that you have an Authorization Endpoint of an AS which is customer facing (which obviously needs to be presented with a certificate that is trusted by the browser) and a desire to mitigate the attack vector called out here which is valid when Particpants are exchanging either credentials (signed_jwt's) or (authorization_codes).

I'm a little puzzled why the UK solution / international solution for this isn't being followed where by you present a different certificate on a different endpoint depending on the transport identification needs.

For example; here's the Coutts (Royal Bank of Scotland's) OpenID Discovery Document. https://secure1.coutts.com/.well-known/openid-configuration

Note how the token endpoint is presented on a different host which allows simple binding with a different certificate which could be an Australian CDR issued certificate. In the example above, the token endpoint for all UK banks require mutual transport authentication even if the OAuth 2.0 application authentication mechanism is private_key_jwt.

Additionally, the Banks are instructed to validate that the application (OAuth) level credentials used are appropriate for the credential used to authenticate the transport layer.

Again all of this is documented and publicly available in both the OpenID FAPI specifications and the UK specifications from which the Australian CDR was supposed to be based. Either way it would be great to understand if there's a reason why this can't be followed in Australia especially considering that it has been implemented by every single bank running every possible combination of tech stack in the UK.

Having a different host name for the different endpoints is permitted if there is a genuine reason to do so... i.e the underlying spec has this clause as a SHOULD not a MUST.

This need to present different certificates qualifies.

Kind Regards, Ralph

[WestpacOpenBanking]

Westpac recommends option 2 – allow any globally trusted root certification authority (CA). We believe that on the balance, this approach is lower risk than the use of the ACCC root certificate authority. This is because we are concerned about the difficulties of maintaining consistent trust stores across the networking stacks of both recipients and data holders. The process is generally prone to human error and increases the risk that certificate validation would be disabled in production, either via code leakage into build pipelines or network device misconfiguration. The customisation required to implement different domains and certificates for different TLS endpoints where it is not supported by identity platforms or client libraries increases these risks materially. In addition, altering a trust store based on the public API used is prone to error, and so is also typically not regarded as best practise.

The attack vectors discussed in issue 65 apply in either one of two circumstances:

1. A successful attack on a certificate authority’s internal infrastructure leads to a compromised signing certificate. This can be used to establish a rouge certificate authority.
2. Compromised DNS Setup - A Data Holder’s DNS Server is compromised, with its entries “poisoned” leading to redirections to a malicious domain or server. In order for this attack to be successful, an attacker will also need to compromise the certificate authorities signing certificate so as to avoid client certificate errors whilst appearing to resolve to a legitimate data holder.

This is possible with either of the proposed options. Both attack vectors will apply regardless of whether a global or private certificate authorities are used for the TLS endpoints. Global certificate authorities are generally auditable entities which have well established security processes and controls. They also have established processes to push certificate revocation to popular trust stores (e.g. Browsers, iOS, Android) which would serve to lessen any impact on the ecosystem in the event of a signing certificate compromise. The use of a global CAs for some endpoints helps mitigate the risk of a total eco-system breach should the Register’s certificate authority be compromised.

[commbankoss]

Commonwealth Bank does not understand how this attack vector could be executed. In order for an ADR to successfully connect to a “fake” token endpoint hosted by a malicious actor the malicious actor would need to hold an ACCC certificate as in the standards it specifies that : “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.”. We recommend that specific industry test cases are included to test this provision. In the event that the malicious actor was an entity certified by the ACCC and held legitimate ACCC issued certificates – the recommended controls would not address the situation. Consequently Commonwealth Bank recommends that the adoption of option 2.

[NationalAustraliaBank]

NAB have reviewed the issues and believe the risk is low, however we acknowledge the threat highlighted is reduced using ACCC issued certificate. NAB are willing to accept the usage of ACCC certificates for TLS endpoints (jwks and openid configuration) so long as the lead times for provisioning a new DNS and associated impacts to industry testing are acknowledged and accepted by the regime. NAB don’t agreed that option 1 is a valid option and going back to MTLS would cause further delays.

[perlboy]

Since a number of parties have contacted me privately regarding this I am crossposting my response. As stated before I see no further value in trying to explain public key cryptography to parties who don't appear to have understood it to begin with. The primary driver for posting this is to "set the record straight" regarding my opinions within Data61 and the DSB while I was working there:

1. If the intent of (M)TLS is securing data in transit only a private CA adds limited value and, in fact, could represent an increased risk as it presents a single point of attack for a bad actor (ie. forging of CA certs)
2. If the intent of (M)TLS is to provide an additional layer of Register endorsement then this should be rigidly enforced across the entire ecosystem (Auth endpoints, Authenticated Resource Endpoints AND Unauthenticated Resource Endpoints such as product data)
3. If the Register implements an intermediate CA it needs to consider whether the root CA vendor has sufficient controls in place to secure a nationwide ecosystem. Making a decision based on "lowest cost" could be very detrimental.
4. If the Register implements an intermediate CA it needs to consider whether it's internal controls meet the standards expected of an intermediate CA. Given this appears to be the ACCC's first major technology project this is no small undertaking.
5. For Holders (OP):
   • TLS, from any CA, private or otherwise, does not adequately mitigate for potential man in the middle or deception attacks, this is why there is SSA's and HoK within OIDC operations and heavily adopted standards like DNSSEC+TLSA in transports.
   • Enforcing MTLS on Globally Standardised endpoints (ie. OIDC discovery, webfinger etc) will likely break compliance and therefore certification of software which follow these specifications (ie. Vendors will lose their OIDF Certified logo).
   • TLS from a Private CA MAY provide for enhanced border protection as it allows explicit CA inspection but this is more a DoS consideration than a party validation one and doesn't seem like sufficient justification given there are much cheaper forms of DoS attack
   • Allowing purchase of certificates from a vendor of the Holder's choosing is likely to have low friction with respect to audit and compliance standards within individual institutions and also spreads risk across multiple CA's
6. For Recipients (RP):
   • Use of the Register CA for client certificates potentially saves Recipients money but the amount of money saved is likely insignificant in the context of implementation
   • Allowing Recipients to purchase their own client certificates from a vendor of their choosing is likely to have lower friction to their audit and compliance policies
   • Allowing Recipients to purchase their own client certificates distributes risk across multiple CA's making the impact of a single CA being compromised lower
   • Where the Register CA is in play, allowing Holder's to implement endpoints, of any type (auth, resource, unauthenticated) using a non Register CA introduces complexity with regards to keystore management and Recipients validating Holders during transport comms. This complexity is reasonably large (but was disputed) and could be detrimental to the ecosystem as a whole as it will likely involve Recipients with unified code bases loading all Global CA AND the Register CA. The end result of this is almost zero validation by Recipients of Holder's endpoints, consequently exposing them to the attack vector presented.
   • Should the ACCC wish to cascade the security provided of using MTLS certificates to Holders (as opposed to just the JWKS + SSA obtainable only via a client cert) it can potentially add the public signature of a Recipient's client certificates to the SSA allowing inspection at registration time (ie. prior to HoK binding) by Holder's although there are cleaner solutions to this problem.

The summary for me is, and always has been, if you are going to use a private CA as a border control for the entire ecosystem you SHOULD use it for ALL endpoints involved in the ecosystem intended for consumption between Holder -> Recipient (ie. everything except the browser presentation layer). The moment a Global CA is allowed in ANY endpoint the border control intended has a hole in it and the risks start outweighing the benefits.

All of this discussion, at the time, was initiated by the consideration of unauthenticated (what the DSB calls "public") endpoints being allowed to use a Global CA. I vehemently opposed this allowance primarily because of the fracturing of the trust chains in use within the ecosystem and the subsequent precedent it implies. Besides being gagged on providing this commentary the decision was to go another direction on the basis "the banks" wanted to use these unauthenticated endpoints for serving content to browsers. I did not see this as reasonable justification for the flow on impacts this meant to the ecosystem trust chain but it seems these impacts were not understood, now, here we are discussing them (quod erat demonstrandum comes to mind).

Consequently, with the decisions now made, I see a diminishing return of having any Register CA involved in Holder<->Recipient comms. Holder's gain little from TLS endpoints secured by CA's they don't have existing policies around and the MTLS certificates presented by Recipients can be verified via a variety of other means. Recipients in the current situation will, at best, be maintaining two trust stores (one with Global CA's + Register CA and one with just Register CA) and, at worst, loading all the CA's in one trust store and blindly accepting the validity of a Holder if it resolves in DNS, it's hostname matches and the certificate is signed by any CA.

If participants on both sides wish to ensure non-repudiation at endpoints there are better solutions such as DNSSEC+DANE-TLSA which, if the DSB/ACCC chose to, could be enforced on all participants, have known and proven implementations, are relatively easy to implement, in fact, all four Holders ALREADY present DNSSEC so adding TLSA is likely a few clicks away. This approach would allow for both Holder and Recipients to verify the counterparty during operations (ie. JWKS retrieval and Dynamic Registration) prior to HoK association occurring.

[anzbankau]

With regards to MTLS vs TLS ANZ is happy to go with the consensus of option 2.

With regards to the ACCC CA vs Global CA we have discussed the threat with our security team and our view is the attack execution as described would be the same regardless. We are in position to move forward with either option.

[ralphbragg-ob]

Hi,

In a nutshell, does the ecosystem want to ensure that all Machine - Machine communications and security / trust processes use key material issued from an appropriately qualified CA that is implicitly, through the act of issuance, confirming authorized status to engage in the ecosystem.

In the UK all endpoints that are machine consumable all are presented with the certs from same CA which gives a lot of the benefits in control, and simplification outlines in Stuart’s email.

In Europe, consumers machine consumable endpoints must be presented / protected with an eIDAS qualifier certificate that is not only issued by a qualified trust service provider but that the certificate confirms to a specific structure - this is a legal requirement.

If the ACCC / doesn’t wish to have control over its participants in this manner nor do the ecosystem believe that their MATLS infrastructure could be simplified by reducing the trust stores to a single trusted root then for the sake of simplicity using public CAs might be acceptable however.. the ACCC should put SLAs on all data holders to ensure that they update their trust roots periodically (which by experience doesn’t happen regularly enough) to ensure that they will always accept ANY public certificate that a data recipient chooses to present.

The number of trust relationships with this approach significantly grows and the responsibility for communications will now rest on both parties making sure they have each other’s chosen trust provider in their trust stores. Playing Devils advocate, If I was a nefarious data provider looking to exploit / disrupt my competitors within the rules of this proposal I would migrate my certificate often and to what ever latest “new PKI” provider that I decided met the definition of “public and trusted” to try and induce communication failure, outages and therefor increased costs on competitors which, in some cases, could be materially damaging.

The ACCC / Data61 needs to recognise the risks to stability that Cert migrations, particularly issuer changes may bring to the ecosystem and decide what rules it will put in place to mitigate - this issue then compounds as this ecosystem moves cross sector.

“I am a Bank, that has 1000 trusted connections, and I’m about to switch issuer which could break these connection”. Whose responsibility is it to notify? How long for? Who decides what “widely trusted is”? (Support by browser? If so which ones and what version”)?

Will the ACCC / Data61 provide a list of Qualified or Appropriate publicly ROOT and Issuing certificate authorities that all participants must use, when they must be supported and are their any anti-competition issues with this approach?

[cdradr]

Good points @ralphbragg-ob. Is it concerning that CDR was about to go live in February with basic foundations not agreed?

[CDR-API-Stream]

@cdradr suggesting that this discussion represents an absence of fundamental foundations is a misrepresentation of the maturity of the standards and an unhelpful contribution. All contributions are welcome to this process but it is requested that they are made within the constraints of the rules of engagement.

[CDR-API-Stream]

The DSB has received notification that the DSB Chair has received a request from the ACCC that this issue be dealt with as an urgent change.

As such, the recommendation that will be made to the DSB Chair for consideration will be to remove the constraint that end points in the Information Security profile that are indicating as requiring TLS must use a certificate from the CDR CA.

Specifically, this would entail the removal of the note at the top of the security end points section referring to the requirement for TLS end points to use a certificate from the CDR CA.

The decision on whether this recommendation will be adopted, and in what time frame, will be made by the DSB Chair.

[CDR-API-Stream]

This has been incorporated into v1.2.0 of the standards.