Decision Proposal 033 - Use of TLS-MTLS

[JamesMBligh]

UPDATED PROPOSAL PUBLISHED

This decision proposal relates to a technical decisions in relation to the securing of communications between participants in the Consumer Data Right regime using Transport Layer Security (TLS)
and Mutual Authentication Transport Layer Security (MTLS).

It is anticipated that feedback will be closed for this proposal on the 19th of October.
Decision Proposal 033 - Use of TLS-MTLS.pdf

-JB-

[ellenbroad]

After discussions in the Advisory Committee about the volume of decision proposals coming over the next few weeks in the lead up to the first full draft set, and difficulty for teams responding when we post at ad hoc times (sorry about that everyone!), we're staggering feedback deadlines. We've established a cadence such that for any decisions published Monday-Thursday in a week, feedback deadlines will the following Friday. This means that while we might upload proposals on different work streams throughout a week, there will always be at minimum seven days for responses, based on a Friday cycle.

As such, I've just edited the due date for this submission to be next Friday 19 October.

[darkedges]

Do we know if there will be enough adoption of TLSv1.3 in the browser space? In terms of consumers, not browsers.

[tlodderstedt]

How is the OAuth authorization server supposed to checkt the redirect_uri against the certificate extension data? I’m asking since client certificates are not available at the authorization endpoint. MTLS uses certificate based authentication at the token Endpoint, after the AS had redirected the user agent back to the RP.

[RalphBragg]

How is the OAuth authorization server supposed to checkt the redirect_uri against the certificate extension data? I’m asking since client certificates are not available at the authorization endpoint. MTLS uses certificate based authentication at the token Endpoint, after the AS had redirected the user agent back to the RP.

One of the confusing issue's is that MTLS in this paper refers to what OBIE defined as MATLS explicitely to avoid confusion with MTLS the Token Endpoint Authentication Mechanism. I'm collating a document with feedback on this proposal, i'll add this a minor note to recommend changing the reference to avoid confusion. I agree with the point by the way, it's not clear at all how this would be used. It's not a "one off" as part of registration (good practice), it's static, tied to the certificate and goes against the recommendations called out and explicitely referenced in the security considerations of FAPI RW. Given that FAPI RW requires signed requests there's far more standardized approaches that are a lot less brittle and aren't remaking the same mistakes as seen with PSD2 eIDAS in Europe where attributes that aren't appropriate for an Identity Record are bolted into the certificate.

i.e Sign a request (certificates or keys for the purpose will be required as part of adopting FAPI RW) for Onboarding / Registring with an OP (Open Banking Standard) or use the MATLS connection as a means of identification and allow the registration to be not signed (RFC 7591 or Open ID Connect Registration). Either approach would be much more flexible, more standards compliant and more in line with seperation of concerns.

Let Transport Security (MA or PFS) be the domain of Transport layer and the OAuth client / RP configuration the domain of that layer. If pinning is required between layers (token binding (better) or DN binding (OBIE UK)) then that is fine as well but poor seperation of concerns results in a very inflexible ecosystem.

In some cases it also goes against good established practice, e.g Registration / pre-registration of URIs is required, they all should be different at each OP, which means lots of certs would be required (also bad practice) or a decision to ignore the security concerns and recommendations for redirect URIs called out in FAP RW which has been submitted as the recommendation for adoption with the stated aim of avoiding deviating unless it's absolutely required.

A more holistic approach is needed to the security designs of the ecosystem. Each decision maker / author can not nor should they be attempting to solve all the issues in a single proposal.

Registration, Identity, Security including Non Repudaition, Authorization can't be decoupled from each other very easily. If we could have confirmation from the ACCC that participants will be required to obtain/provide certificates / keys, that identify each party, for the purposes of MATLS (this topic) as well as Signing (Implicit in the adoption of FAPI RW) then how topics like how to do OAuth client registration including secure specification of redirect URIs in a standards fashion become very simple). The specs have already been written for this purpose.

[mperryau]

As alluded to in Ellen's update, I do not see any reason to diverge from the FAPI standard in this instance and we hope this is reflected in the updated document to come.

Mark Perry
APAC CTO, Ping Identity
Consumer Data Right Advisory Committee member

[darkedges]

Do we need to create a new certificate for every new / additional redirect_uri change? Does this add an overhead on Certificate Revocation etc?

Mind you under the UK model, I would need to create a new Software Statement Assertion and register that with the Authorization Server, but that did not create a new certificate, instead it was a new signed JWT.

[darkedges]

Does this mean that the Authorisation Server needs to use the value of the redirect_uri in the certificate, instead of the one registered for the client? What happens if I have multiple redirect_uri values, say mobile vs desktop, how do I tell the Authorisation Server which one I need to use?

[cjemichael]

I'm guessing the comments on this may be closed now? OBIE have moved to fully support FAPI (and CIBA) moving forwards, and it would be good if more took the same stance on this. Will help vendors, banks, third parties and ultimately benefit customers if there is a global alignment here.

[jogu]

@darkedges I think it would be a bit early to start mandating TLS 1.3. In the backend:

• java: TLS 1.3 requires java 11, which is not yet in wide use having only being released last month ( https://bugs.java.com/view_bug.do?bug_id=8202625 )

• debian stable does not support TLS 1.3 ( https://wiki.openssl.org/index.php/TLS1.3 https://packages.debian.org/search?keywords=openssl ).

I would say it would be best to align to the FAPI requirements (which is currently TLS 1.2). The FAPI standard would be updated to require TLS 1.3 when it becomes sufficiently well adopted.

[NationalAustraliaBank]

NAB does not recommend mandating the use of TLS 1.3 for the phase 1 scope in July 2019; the standard is new and will take time to become widely adopted, tested and trusted.

Please note: the FAPI UK Read-only profile outlines the use of TLS 1.2 or higher:

**TLS considerations**
As confidential information is being exchanged, all interactions shall be encrypted with TLS (HTTPS).
The recommendations for Secure Use of Transport Layer Security in BCP195 shall be followed, with the following additional requirements:

- TLS version 1.2 or later shall be used for all communications.

- A TLS server certificate check shall be performed, as per [RFC6125].

https://openid.net/specs/openid-financial-api-part-1.html#tls-considerations

[robdylan13]

I would add my voice to those above and query the usefulness of including the redirect_uri in the certificate used for MTLS. Redirect URI's are unique per software client and could potentially change over time. It is required that these URI's are registered ahead of time at the authorisation server and if the Request Object mechanism as mandated by FAPI is used, we will obtain a signed assertion from the client in any event indicating which of the pre-configured redirect_uri values should be used. Overall, this is a far more flexible approach and doesn't seem any less secure than what has been proposed.

Rob Otto
Office of the CTO, Ping Identity

[JamesMBligh]

A new version of this proposal has been uploaded in the issue description. Please find below the original, deprecated version which is added here for transparency.
Decision Proposal 033 - Use of TLS-MTLS.pdf

-JB-

[commbankoss]

CBA is not yet able to fully endorse Decision Proposal 33 due to several issues that remain open which we believe invite increased risk exposure.

The Decision Proposal does not discuss authentication and authorisation in the event that a decoupled flow to customer authentication is adopted. CBA strongly recommends this is considered, if not in this Proposal then in subsequent ones.

We also recommend that cryptographic key length specifications are improved to make the minimum permissible key lengths longer, to both align with Banks own internal standards or policies, and industry best practice.

To prevent the replay or use of stolen access tokens by malicious or unauthenticated third parties, CBA recommends that Option 2 in the 15th October Decision Proposal also include the adoption of certificate bound access tokens with MTLS

MTLS should be used to encrypt all communications between data consumer and data provider. The Decision Proposal dated 9th October indicates (on page 2) that “Consumer to Authorization Endpoint of Data Holder communication (directed or CIBA) is protected by TLS using a server side external certificate”. This process should utilise MTLS.

In our view, private_key_jwt based authentication needs to be considered alongside MTLS, rather than as two non-compatible tools. MTLS authentication, as part of the current process, would likely terminate at the ‘reverse proxy’, thereby leaving no protection between the proxy and the gateway. private_key_jwt authentication would extend the levels of protection and reduce this risk.

[jogu]

The Decision Proposal does not discuss authentication and authorisation in the event that a decoupled flow to customer authentication is adopted. CBA strongly recommends this is considered, if not in this Proposal then in subsequent ones.

In my opinion the best thing to do here would be to use the FAPI profile of CIBA, as OpenBanking UK plan to do. An implementers draft of that spec is expected to be ready within a few weeks I believe.

MTLS should be used to encrypt all communications between data consumer and data provider. The Decision Proposal dated 9th October indicates (on page 2) that “Consumer to Authorization Endpoint of Data Holder communication (directed or CIBA) is protected by TLS using a server side external certificate”. This process should utilise MTLS.

"Consumer" here means "end user" (only the end user accesses the authorization endpoint), and this access is done in the user's browser. MTLS would not be desirable here, distributing client TLS certificates to end users and getting them to install them would be a nightmare.

To prevent the replay or use of stolen access tokens by malicious or unauthenticated third parties, CBA recommends that Option 2 in the 15th October Decision Proposal also include the adoption of certificate bound access tokens with MTLS

Certificate bound access tokens are mandatory in the FAPI R/W profile, so my understanding is that option 2 would mandate them.

We also recommend that cryptographic key length specifications are improved to make the minimum permissible key lengths longer, to both align with Banks own internal standards or policies, and industry best practice.

Could you expand on exactly what you are proposing here please?

FAPI part 2 already limits the ciphers used (and hence the symmetric key sizes); when following FAPI it is permitted for a bank to disallow the 128 bit GCM variants.

FAPI also requires that the BCP195 recommendations on key length are followed ( https://tools.ietf.org/html/bcp195#section-4.3 ).

[commbankoss]

"Consumer" here means "end user" (only the end user accesses the authorization endpoint), and this access is done in the user's browser. MTLS would not be desirable here, distributing client TLS certificates to end users and getting them to install them would be a nightmare.

If a redirect approach is implemented we agree, the end user will talk to the authorization endpoint and MTLS will not be viable. In a de-coupled approach we would not expect the end user to talk to the authorization endpoint directly.

In summary CBA holds the view:
· MTLS to be used for all communications between Third Party (Accredited Receiver) and Bank (Data Holder)
· TLS to be used for all communication between End User (Consumer) and Bank (Data Holder)

We are however advocates for the progression of the FABI CIBA profile, and look forward to reviewing the final profile specification once release.d

CBA would also like to affirm its opinion that the ciphers referenced in Option 2 (Align with FAPI Read/Write Profile) in the second document would be the most suitable for use within the CDR. It is important to reiterate the necessity of suitable key lengths given that the first of the two documents mentioned use of 80 bit key length.

[bazzat]

The ABA Open Banking Technical Working Group was unable to achieve a consensus position supporting the recommendation in DP033. We recommend holding this DP open to allow further discussion before adoption.

[JamesMBligh]

I am leaving this proposal open until COB Monday at the request of a number of stakeholders

-JB-

[MacquarieBank]

Open Banking Security Standard and MTLS Scope

Macquarie, as per other respondents, does not fully endorse the latest decision proposal version that has iterated to just focus for the most part on Option #3 from the prior proposal version and also does not provide enough clarity in relation to role of the of the ACCC Register and the apparent overlap of concerns and mechanisms between transport security and application security.

Macquarie, as one of the first Australian Banks to have an operational Open Banking Platform in the Australian market, strongly endorses the evolved UK Open Banking Security Standard (including adoption of the Financial API R/W) for its clarity in clearly setting out the layered but separate security mechanisms of the standard as follows:

“The Open Banking Security Standard defines how the Read/Write APIs need to be secured using a multi layered approach. The OAUTH 2.0 authorisation framework and Open ID Connect identity authentication are layered over mutually authenticated transport layer security (MATLS) to provide a robust and secure security profile.

The Security Profile also uses the OpenID Foundation’s Financial API (FAPI) Read and Write API Security Profile. This specification is published on the OpenID Foundation website at openid.net”

Specific to the proposal, mandating the use of TLS 1.3 is not supported but rather maintaining alignment to the FAPI profile that states ‘TLS version 1.2 or later shall be used for all communications’.

FAPI R/W Security Profile position

In relation to the FAPI R/W API Security Profile, whilst for largely legacy reasons, it supports the use of either OAUTB or MTLS methods as a holder of key mechanism and MTLS or private_key_jwt (JSON Web Token) for authentication of the confidential client at the token endpoint (Authorisation server), it is Macquarie’s strong recommendation that the CDR standards adopt a principle to only support OAUTB and private_key_jwt to ensure that transport security is kept at the Layer 2 transport layer and Application security is implemented only at the Application layer (Layer 7).

The OIDC standard definition of private_key_jwt is as follows:

Clients that have registered a public key sign a JWT using that key. The Client authenticates in accordance with JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants [OAuth.JWT] and Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants [OAuth.Assertions]

https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication

Data Tampering Prevention with JOSE

To address concerns about data tampering that are not addressed by the FAPI R/W profile, Macquarie further recommends adoption of the JavaScript Object Signing & Encryption (JOSE) specifications rather than MTLS. The JOSE specifications consists of the following components:

JWS JSON Web Signature (RFC7515) - defines the process to digitally sign a JWT

JWE JSON Web Encryption (RFC7516) - defines the process to encrypt a JWT

JWA JSON Web Algorithm (RFC7518) - defines a list of algorithms for digitally signing or encrypting

JWK JSON Web Key (RFC7517) - defines how a cryptographic key and sets of keys are represented

[da-banking]

Inclusion of a fingerprint property
On the proposal to include a "fingerprint" of the Accredited Receiver client certificate in the JWT returned by the authorisation server, we would like to clarify that the fingerprint should be the public key fingerprint and exclude from its hash the validity dates (not before, and not after).

The fingerprint should remain the same even if the private key is re-issued.

The proposal uses the term certificate hash, which might mean a hash of the whole certificate. If the fingerprint was from a hash of the whole public key, or the private key, then rotating the client certificate would invalidate all stored tokens that were bound to the retired client certificate by fingerprint. This would be undesirable.

redirect_uri in a client certificate
Since a single Accredited Receiver may have multiple clients that access Open Banking resources, it seems that the inclusion of a redirect_uri as a custom property in the client certificate ought instead to be a white-list of allowed places to deliver the token to. The Authorisation server of the data holder, should redirect to the specified redirect_uri if the specified redirect_uri is on the white-list in the client certificate.

Ideally the Accredited Receiver should be able to edit their own white-list.

We can accept either the inclusion of a white-list in the client certificate itself, or a white-list passed on the request that can be verified with the client certificate to have been signed by the Accredited Receiver.

No direct browser or app clients
We would call out that the use of MTLS effectively rules out consumer facing clients (browsers and apps) from directly accessing CDR data, without a private server-side middleware between the client and the data holder.

Section 10 Providing consumer data to consumers ACCC CDR Rules Framework states that:

At a high level, the ACCC proposes to make rules that would require data holders to ... provide consumers with the ability to make requests for direct disclosure of their CDR data in a manner that is timely, efficient and convenient. Likely minimum requirements are that:
...
b) the data holder must also allow consumers to access CDR data via an open API

In section 10, essentially the ACCC are setting out the principal that if data holders have to provide data to accredited data recipients, then they should also provide data directly to the consumer via API. MTLS mediated by a central ACCC Registry/Certificate Authority is not going to solve this.

Will Data61 be defining a standard mechanism for consumers themselves to access their own data via APIs?

[JamesMBligh]

Thanks for all the feedback folks. Much of it aligns to the intent of the proposal - aligning with FAPI R/W, TLS 1.2 and above, MTLS for comms between data provider and data consumer, etc.

A lot of the feedback relates to other decisions and this has been noted for future reference.

Feedback will be collated and a final recommendation made to the Chair with review by the Advisory Council.

-JB-

[JamesMBligh]

Due to issues with GitHub on Monday ANZ were unable to post their feedback before the cut off so I am posting their feedback here on their behalf.

-JB-

---

ANZ has concerns that cipher suites including DH Export for key exchange are susceptible to “Logjam” attacks and that we note that when all security and operational considerations are taken into account, the proposal leaves only two cipher suites we would be willing to support under the FAPI Read/Write profile:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Therefore we express concern that the decision proposal is restrictive in nature and seek to clarify that the statement

For all interactions except for authorisation only the following cipher suites may be used:

does not imply that all [the stated] cipher suites must be supported

Where use of DH cipher suites of FAPI R/W is considered, we strongly recommend that key size of over 2048 bit is mandated to close any vulnerabilities associated with downgrade of key size.

ANZ also support the view of client authentication using private_key_jwt for added security as per OIDC
https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication

[JamesMBligh]

Again, due to GitHub server issues David Tonge (CTO Moneyhub and OIDF FAPI WG Co-chair) was unable to post the feedback below.

-JB-

---

@MacquarieBank I think there is confusion between client authentication and "proof of possession" tokens.

• private_key_jwt is for client authentication

• MTLS (i.e. https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/) is for client authentication AND proof of possession tokens

• OAUTB is for proof of possession tokens

For client authentication there are pros and cons to each approach, but neither is legacy. If its easier key rotation that you are interested in or avoiding the need for a CA, then MTLS can also support this with the use of self-signed certificates. I agree that there are benefits in keeping the transport and application layers separate, but MTLS can be implemented in such a way as to let the actual authentication decision be made at the application layer.

For proof of possession tokens, MTLS is now widely in use to support this and is easy to implement. OAUTB is to my knowledge not widely used yet in this kind of context and is harder to implement due to the lack of maturity of the libraries and the requirement to patch the TLS stack (e.g. OpenSSL).

FAPI supports both, and it would be advisable for any new standard to follow this approach.

Re tamper-proof messages, FAPI Part 2 already supports this with its requirement to use the Request Object and OIDC Hybrid mode / OAUTH JARM (i.e. JWTs

I hope this helps to clarify things.

[JamesMBligh]

The finalised decision for this topic has been endorsed. Please refer to the attached document.
Decision 033 - Use of TLS-MTLS.pdf

-JB-