Would the JWKS endpoint also be precluded from mTLS under this change?

From the data recipient perspective, I am supportive.

This change simplifies participation in the eco-system. Cloud providers like AWS don't support client authentication with edge services like CloudFront. The implication being data recipients will need to roll their own TLS termination services.

from standards-maintenance.

I think it's worth looking at why this requirement is in place and what it offers as functional or security posture piece.

If the value isn't there it's worth removing as a means to simplify the amount of moving pieces and being able to again use standard termination from the cloud providers

from standards-maintenance.

As an aspiring ADR, it doesn't make any difference to us from an implementation perspective. The cloud provided services that we have chosen easily support client authentication via MTLS and, while AWS are not one of them, there are several to choose from (e.g. Azure APIM or Cloudflare).

From an overall system perspective, I can see how keeping all endpoints consistent with MTLS requirements makes for a less complexity. And, while I can't argue with the logical rationale presented for the removal of MTLS for the ADR end-points, I can see how requiring MTLS on all endpoints would give regulators (and semi-savvy consumers) the impression (and hence comfort) that the regime is very secure.

from standards-maintenance.

From a process perspective this issue hasn't been prioritised for the current maintenance iteration. It would appear, however, that this could be considered an urgent change to consider for the February milestone.

Is this change considered urgent by the community?

from standards-maintenance.

Not considered urgent at all by us. And with workarounds available for AWS users, I wouldn't expect it to be an urgent issue for others. But we are just one voice in the community, so I'll let others speak for themselves.

from standards-maintenance.

Quoting from the first line of the Standards on Revocation Endpoint:

Data Holders and Data Recipients MUST implement a Token Revocation End Point as described in section 2 of [RFC7009].

I don't believe RFC7009 specifies any MTLS requirements but does require at least TLS verification. In addition OIDC's references on revocation generally make MTLS optional.

On this basis, the enforcement of MTLS means that solutions certified for established and adopted international standards will not be automatically compliant once it gets to system deployment. The flow on impacts on cloud services is also a relevant observation. Of course it's still possible but for implementers it's another work item, I'm not sure the reasons for doing so are fully justified.

The issue here is that Revocation (aka Identity related) & Admin are being grouped into the same context but Revocation is based on existing standards and the Admin endpoint is a CDS specific implementation. That is to say 1 is inherited from the software landscape and 1 is a definite build for CDR recipients.

Notwithstanding the security wins associated with pure MTLS, my suggestion would be to align Revocation with the existing international standard but retain MTLS for ACDS/Register "domain" endpoints.

By clearly defining the boundary between the ACDS spec and the international ones it refers to would be helpful to implementers. A diagram of this would be very helpful.

Finally, post initial smoke testing of a functional end to end a follow up security review that considers the full context between CDS and Register structure seems relevant.

from standards-maintenance.

For clarity, section 2 of RFC7009 states:

Implementations MAY also support additional transport-layer security mechanisms that meet their security requirements.

So my interpretation is that requiring MTLS for the CDR implementation does not result in non-compliance with RFC7009 and remains aligned with the international standard.

But I do like your logic, @perlboy, so would be supportive of your suggested approach and agree that there will be many items to be discovered through the E2E testing.

from standards-maintenance.

So my interpretation is that requiring MTLS for the CDR implementation does not result in non-compliance with RFC7009 and remains aligned with the international standard.

That's a good pickup, there is some mention of MTLS in the RFC, thank you. Nonetheless this converts a MAY to a MUST, key difference here is Standard <-> Standard vs. Standard <-> "implementations". When you are setting it for the first time there's more flexibility but varying established specs (especially that one) needs strong justification.

But I do like your logic, @perlboy, so would be supportive of your suggested approach and agree that there will be many items to be discovered through the E2E testing.

Thanks 👍, yes, there will always be interop issues to deal with and when it's a justified variation it makes sense. Nonetheless I don't see the reasoning for Revocation to have MTLS save for protection against an enumeration attack on a high entropy token.

from standards-maintenance.

See also Issue 40:

Request For Clarification

Data Holders, Data Recipients and the Register must all host JWKS endpoints to allow for verification of public keys for a variety of purposes. Typically, these endpoints do not require mutually authenticated TLS. This approach allows distribution via a CDN and increased resiliency without security impact.

Currently, the transport security required for Data Recipient implementations is not specified. If intended, we would need to customise our security infrastructure to support TLS-MA instead of TLS. To align with standard approaches, and the approach used for the registry hosted JWKS endpoint we suggest that TLS without mutual authentication is the most pragmatic option for February.

We also query as to if the requirement for Data Holders to require TLS-MA for their JWKS endpoint was intended, and if so, the rationale for this approach.

from standards-maintenance.

Commonwealth Bank supports the removal of MTLS for ‘Token Revocation endpoint for consent withdrawal’ and ‘Admin Endpoint for Metadata Update’. Deployment of MTLS assists in mitigating against token compromise and replay attacks. However, these are not relevant risks for the endpoints in question which use private_key_JWT for authentication.

from standards-maintenance.

There is a lot of commentary on this thread and it has also been raised in various workshops. The DSB would be happy to accommodate this change in the next maintenance iteration.

Some of the commentary, however, implies that this is something with impact for February. If the issue is considered urgent we can fast track a change.

Is the issue considered urgent for February?

from standards-maintenance.

Frollo supports the removal of MTLS for ‘Token Revocation endpoint for consent withdrawal’ and ‘Admin Endpoint for Metadata Update'.

from standards-maintenance.

The ACCC has identified that this issue affects current testing and therefore is considered urgent for February,. Can this issue please be fast tracked?

from standards-maintenance.

Commonwealth Bank continues to recommend removing the need for Data Recipients to host any APIs for Data Holders or the registry for February 2020 phase of CDR. This will:

• Simplify the ecosystem by removing the need for ADRs to host API, API security infrastructure, authenticate and authorise API callers (Registry and Data Holders).

• MTLS on ADR side #43 will not be required.

• Client Authentication on ADR side https://github.com/cdr-register/register/issues/24 will not be required.

• Additional security assessment for a new type of interaction will not be required.

Commonwealth Bank recommends that consent revocation notification (from data holder to data recipient) be addressed via a bulk Consent event / revocation API that data recipients can call at agreed intervals.

from standards-maintenance.

Moneytree supports the removal of the following requirements for ADR:

• MTLS for Token Revocation endpoint for consent withdrawal
• MTLS for Admin Endpoint for Metadata Update
• MTLS for JWKS endpoint

from standards-maintenance.

Intuit also supports the removal of TLS-MA for

• JWKS endpoint
• Token Revocation endpoint
• Admin endpoint for metadata update

For the reasons that:

• JWKS can be distributed by CDN; industry practice is just TLS; security threat on exposure of public keys seemed to be limited
• Token Revocation and Medatadata update endpoints both require private_key_jwt signing. This seems to provide higher level of client validation than TLS-MA in that typical TLS validation typically only goes to Root/Intermediate level and not down to the leaf. That is, TLS-MA essentially only validates the client is within the CDR regime but not the actual client.

from standards-maintenance.

We support the removal of MTLS for JWKS end points of both ADRs and ADHs, and understood this to be the current position, as per:
#40 (comment)

For the remainder of the end points we support the current position of the standards, given this:
• Provides extra security for data recipients.
• Doesn’t impact current implementation.
• Maintains consistency between ADR and ADH end points.

from standards-maintenance.

As noted, there are no access tokens provided to these endpoints and so Holder of Key is not relevant to either scenario. Removing the requirement for mutually authenticated TLS does reduce security at the transport layer, but our initial analysis suggests that there is sufficient security at the application layer to compensate in these cases. We note that to reduce the likelihood of successful abuse of the revocation endpoint, it is important that refresh tokens have sufficient entropy.

from standards-maintenance.

To address the urgent requirements raised and based on the feedback provided the DSB will recommend the removal of the requirement for MTLS for:

• ADR hosted revocation end point
• ADR hosted metadata update end point
• ADR hosted JWKS end point
• DH hosted JWKS end point (as per discussion at #40)
• DH hosted OIDC discovery end point

Note that the DSB will not be recommending the removal of the ADR end point for revocation. As discussed previously, this is due to the need to align with the CDR Rules.

This change will be recommended to be made to the standards in the next release (v1.1.0) that is scheduled to be published at the end of this week and will take immediate effect.

from standards-maintenance.

Based on review of other, related, threads the holder hosted OIDC discovery end point has been added to the recommendation above for clarity.

from standards-maintenance.

A decision issue on the main standards repository to accommodate the Chair's decision in this matter has been created at: ConsumerDataStandardsAustralia/standards#92

from standards-maintenance.