Decision Proposal 065 - Transaction Security

[JamesMBligh]

This issue has been opened to capture, document and obtain feedback on a subset of the Information Security profile for the CDR regime with a view to finalisation and endorsement by the Chair of the Consumer Data Standards body.

This issue is specifically related to the securing of transactions under the regime.

The decision proposal is attached below. Feedback will be closed on 10th May.
Decision Proposal 065 - Transaction Security.pdf

[JamesMBligh]

Decision proposal has been published.

-JB-

[JamesMBligh]

An concern has been raised within the DSB about a potential security weakness regarding transaction security.

Specifically, it has been suggested that the of TLS for the public data APIs (ie. product data) using any CA that the holder prefers combined with the requirement the MTLS be used for secure data APIs (ie. accounts, transactions, etc) could result in a scenario that could expose a Man-In-The-Middle attack risk. A client that loads the global CAs as well as the CDR Intermediary CA in their truststore (say as part of the JVM configuration) could be fooled, via a DNS hijack of a holders DNS host entry to honour communication with a malicious server if a certificate for the same host was in another CA other than the CDR CA. It is suggested this could then be leveraged to access data returning from the holder on the secure APIs that have MTLS implemented on them.

The suggested remedy for this is to require that the certificate used for the public product reference APIs should also be provided by the CDR CA.

Feedback on the validity of this concern as well as the likely risk profile and whether the suggested remedy would be acceptable would be most welcome.

-JB-

[csirostu]

Since there appears to be a continued misunderstanding of the issue I'm raising internally I shall reiterate it here. From the proposal the following is stated:

End points for transferring CDR Data that is considered public and unauthenticated do not require the use of MTLS

After initial clarification the implication of this sentence and prior, assumed and unpublished statements is that Data Holder's will be able to present what is currently referred to as Public APIs using any TLS certificate issued by any Global CA (ie. not the Registry CA). Fundamentally this means that Public APIs do not have an implicit "cryptographic endorsement" by the Registry CA.

The side affect of this is that Data Recipients, who are likely to develop a unified library for consuming all CDR APIs (authenticated & unauthenticated), will now be required to load all Global CAs AND the Registry CA into their trust store in order to ensure all Data Holder's pass server certificate verification. Alternatively they will alter the trust store based on the API they are accessing but, in my opinion, this is not only poor defensive programming practice but is highly prone to human error.

By requiring Recipients to load Global CAs it now also means that rogue CA's (of which there has been a few) who issue certificates for FQDN's matching Holder endpoints without "good" verification would successfully (but incorrectly) pass certificate validation during Recipient communication. Combining this with a compromised DNS setup (or simply a compromised AWS key to alter DNS records with) this could be extrapolated well beyond Public APIs as Recipients would be "fooled" into thinking they were talking to Holders when in fact they were talking to a forged endpoint loaded with a certificate signed by a rogue certificate authority.

From my perspective this is fundamentally around how Recipients verify that the Holder they are interacting with (unauthenticated or otherwise) is indeed the Holder they expect it to be. It is also around making a clear distinction that what is currently called "public" is actually "unauthenticated" APIs and whether "unauthenticated" does (or does not) mean "untrusted".

It also presents the question of whether the Registry (and by proxy the ACCC) is the exclusive arbiter of trust bestowed upon participants irrespective of the API being requested. In the current proposal at a bare minimum this arbitration is broken for "public" APIs such that the Registry is no longer the delegator of this trust (and this could cascade into Data Recipient implementations).

My personal opinion at this stage is that the definition of trust, under any circumstances, of Holder services, authenticated or unauthenticated, should remain exclusively the domain of an Australian Government Endorsed CA (ie. ACCC for the foreseeable future) and their accreditation processes for both Holder and Recipient. On this basis all participants within the CDR ecosystem would EXCLUSIVELY load the Registry CA and remove all Global CAs from trust lines (essentially creating a closed circle of trust among CDR participants). This does not preclude Holders from using certificate bundling to ship intermediate certificates to establish a trust line to Global CAs (via the Registry CAs intermediate CA), thereby allowing clients who do not have the Registry CA loaded to continue unimpeded while still allowing Accredited Recipients to rely exclusively on just the Registry CA.

I would be interested to hear feedback from the community on why we would not consider this to be the best outcome.

Final note for clarity: I am not suggesting that unauthenticated APIs should require MTLS setup (ie. a data recipients client certificate) to be established. Rather I'm suggesting Holders should be presenting their APIs exclusively using server certificates signed by the Registry CA such that Recipients can have strong cryptographic proof that the API they are accessing is delivered by an approved participant in the CDR.

[commbankoss]

Commonwealth Bank is broadly supportive of Decision Proposals 63 and 65. However, to fully endorse the Information Security Decision Proposals we would like to see all the proposed decisions to understand how the various elements interact. It is crucial to look at the full end-to-end journey.

Commonwealth Bank also notes that decisions made in other streams (e.g. CX) may require us to revisit these decision proposals in the future in the event they impact one another.

[anzbankau]

Hi James,

Will there be support for OCSP based validation for certificates issued by CDR certificate authority?

Normative reference to standard - https://tools.ietf.org/html/rfc6960

We are happy with rest of proposal.

Thanks.

[NationalAustraliaBank]

NAB is supportive of the positions outlined in this paper, however as discussed in the InfoSec working group we need further clarity on the use of ACCC issued certificates for public Product endpoints. We look forward to having a view of ACCC's directory design and the proposed implementation of these controls.

[JamesMBligh]

Before closing this issue I would like to specifically seek feedback on the application of CDR Certificates to public end points. The options are:

1. Holder can select an CA for these end points (current position)

2. Holder must procure and a utilise a CDR CA for these end points

3. Holder can select any CA for these end points but must republish these public end points under the Secure base URI as well as at the Public base URI

I will close in the next few days once feedback is obtained. If no feedback is provided a decision will be taken with best efforts to balance the concerns raised.

-JB-

[WestpacOpenBanking]

Before closing this issue I would like to specifically seek feedback on the application of CDR Certificates to public end points. The options are:

1. Holder can select an CA for these end points (current position)
2. Holder must procure and a utilise a CDR CA for these end points
3. Holder can select any CA for these end points but must republish these public end points under the Secure base URI as well as at the Public base URI

I will close in the next few days once feedback is obtained. If no feedback is provided a decision will be taken with best efforts to balance the concerns raised.

-JB-

Maintaining a consistent trust store across an entire stack is a difficult issue – there is typically no single trust store to configure. As pointed out by @csirostu this is prone to human error. However, the risk of a rogue certificate authority or DNS hijacking need to be balanced against the risk of code leaking into build pipelines or misconfigured network devices with disabled certificate validation. We believe that there may be merit in the idea of not having the directory acting as a root certificate authority from this perspective.

In terms of the options presented, we support Option 1. We can technically support Option 2 but do not recommend it with the additional recommendation that the (assumed) conformance suite that Data Recipients will need to pass to obtain or maintain accreditation specifically tests for the vulnerability described by csirostu.

Option 3 is unsupported by our current infrastructure, which separates public endpoints from authenticated ones and requires separate base URIs. This is done so that our security infrastructure can best be configured to deal with the differing types of threats that manifest on public endpoints vs authenticated endpoints.

[NationalAustraliaBank]

To ensure we are aligned, NAB assumes that what Data61 is referring to “public endpoints”, are solely the API endpoints for product data. For this purpose only, NAB is comfortable with the adoption of option 1 (Holder can select an CA for these end points (current position)). As we understand, these endpoints will be exposed to the general public.

The use of CDR issued certificates to secure these endpoints may not necessarily address all the highlighted security concerns outlined on this thread, with Data Recipients (DRs) handling a mix of CDR CA issued certificates and public CA issued certificates. Further security controls must be adopted by DRs to ensure the threats in there articulated are mitigated.

[JamesMBligh]

I will now close this proposal for feedback and produce the final decision. Thanks for the comments.

One last note in response to @anzbankau, I'm afraid that the decision as to whether OCSP will be supported or not is for the ACCC Registry team to address so I am unable to comment.

-JB-

[JamesMBligh]

Please find attached the final decision covering this issue
Decision 061-066,068 - Information Security Profile.pdf