Revocation Endpoint Clarification

[perlboy]

Request For Clarification

Clarity is requested at to what is referred to as the [JWKS] endpoint for Revocation requests from Data Holders to Data Recipients. The Register appears to explicitly define this as API metadata while the Standards appear to imply this is the jwks_uri sourced from the Data Holders discovery document.

Specifically with regards to this endpoint please also clarify the following:

1. The signing algorithm used in the example is PS256 but this is never explicitly specified?
2. The revocation request appears to be an RFC7009 request but, since 1.3.0 this has been omitted. Is the DSB defining a custom specification for token revocation requests? If not, and RFC7009 is intended, this RFC specifies that client authentication is to be handled according to section 2.3 of RFC6749. What authentication method of RFC6749 is being used?
3. Is the Recipient Revocation endpoint intended to be secured using MTLS? If so, why is a signed JWT necessary? If not, what consideration has been given for the potential for a denial of service occurring on the computationally expensive Data Recipient revocation endpoint?

Since ADR's are not operating an IdP and assuming it is intended to be RFC7009 compliant it would appear this revocation request is being sent by an unregistered client. As stated in RFC6749 section 2.4:

This specification does not exclude the use of unregistered clients. However, the use of such clients is beyond the scope of this specification and requires additional security analysis and review of its interoperability impact.

Please provide detail of the security analysis conducted and what mitigations are expected to be implemented by Data Recipients. At a high level a denial of service conducted simultaneously on all recipients appears to be an asymmetric attack vector which could have a significant impact on the stability of the ecosystem as a whole.

As an immediate answer to a likely response, use of Data Holder Brand ID does not represent a "registration" of the client as this data is not secret and therefore correctly structured but invalidly signed JWTs is entirely possible.

[CDR-API-Stream]

There are a number of issues canvassed in the item above and the comments below attempt to clarify as many of these as possible:

• Client authentication of the DH by an ADR when a notification of revocation is made is described in the client authentication section. The DH provides a signed JWT as a bearer token. The ADR uses the JWKS provided at the end point specified by the DH's discovery end point to verify the signing of the JWT to verify identity.
• The ADR hosted revocation end point (replaced at a future date by the arrangement end point as of v1.3.0) is to be exposed using TLS as opposed to MTLS. The DH hosted token revocation end point should be exposed as per the normative standards but must use MTLS for transport security.
• MTLS is never used for client authentication in the CDR standards. It is used only for transport security and as a holder of key mechanism.
• Authentication of an ADR on the DH revocation end point should be performed according to the private_key_jwt mechanism using a client assertion. The JWKS that the DH would use to validate the JWT in this instance would be obtained from the end point specified during client registration in the ADR's SSA (as described by the Registry design)
• Signing and encryption algorithms are not mandated by the CDR standards. The accepted algorithms by DHs and ADRs are exchanged via the OIDC Discovery and Client Registration protocols respectively, according to the normative standards.

Finally, neither the ADR or DH hosted revocation end points can be called by unregistered clients. Both require client authentication as described in the standards.

[perlboy]

• Client authentication of the DH by an ADR when a notification of revocation is made is described in the client authentication section. The DH provides a signed JWT as a bearer token. The ADR uses the JWKS provided at the end point specified by the DH's discovery end point to verify the signing of the JWT to verify identity.
• The ADR hosted revocation end point (replaced at a future date by the arrangement end point as of v1.3.0) is to be exposed using TLS as opposed to MTLS. The DH hosted token revocation end point should be exposed as per the normative standards but must use MTLS for transport security.
• MTLS is never used for client authentication in the CDR standards. It is used only for transport security and as a holder of key mechanism.

These three statements combined appear to result in the ADR exposing a revocation endpoint with no network access control available (since source IP of Holder is not known and MTLS is not in use). I reiterate the following statement: "... what consideration has been given for the potential for a denial of service occurring on the computationally expensive Data Recipient revocation endpoint?"

This question appears to apply to both the existing revocation endpoint requirement and the sharing arrangement endpoint as both rely on a globally exposed API requiring cryptographic signature verification prior to logic processing. In traditional auth server environments a token is issued for a period of time and used across requests and this token is either used for resource server calls or specified as the token to revoke. In the proposed approach every request requires assertion verification (ie. an attack is asymmetric in nature).

• Authentication of an ADR on the DH revocation end point should be performed according to the private_key_jwt mechanism using a client assertion. The JWKS that the DH would use to validate the JWT in this instance would be obtained from the end point specified during client registration in the ADR's SSA (as described by the Registry design)

This question wasn't about ADR -> DH comms. This question was specifically focused on DH -> ADR comms.

• Signing and encryption algorithms are not mandated by the CDR standards. The accepted algorithms by DHs and ADRs are exchanged via the OIDC Discovery and Client Registration protocols respectively, according to the normative standards.

The signing algorithm used from a DH to a ADR is never negotiated nor is it advertised because the ADR doesn't have an OIDC Discovery endpoint. Only the signing algorithm used between an ADR to a DH is negotiated within discovery and registration and this is done on a per requirement basis (ie. request object, id token signing/encryption etc).

On this basis, how does a DH determine what the preferred signing algorithm for client assertions toward recipients are? Does the DH assume that the agreed request object signing method (which is only ever PS256 right now) is the method used to sign revocation requests towards the Recipient?

Finally, neither the ADR or DH hosted revocation end points can be called by unregistered clients. Both require client authentication as described in the standards.

A publicly exposed endpoint can always be called by an unregistered client, it may simply be denied, typically during signature verification which was the crux of the original question with respect to an ADR's revocation endpoint being potentially DoS'd and, to a lesser extent, used for distributed reflection attack of a Holder.

[cdradr]

Has anyone performed a formal threat and risk assessment of this interaction?

This appears to be a security gap with potentially damaging consequences for other participants.

[perlboy]

@JBRedcrewAdmin Should this be classified as a DSB response or a response from an involved party?

Either way, the signing algorithm negotiation method hasn't been clarified.

[EDIT]: Since response has been deleted, repasting screenshot to ensure future context:

[cdradr]

@perlboy It looks like some sort of a vendor but it’s not clear what they are selling exactly and to whom: https://www.redcrew.com.au/.

Would be great if Data61 or ACCC can clarify or provide an official response to @perlboy query. We had similar questions.

[perlboy]

@perlboy It looks like some sort of a vendor but it’s not clear what they are selling exactly and to whom: https://www.redcrew.com.au/.

It's a little deeper than that, Red Crew made a submission to the Parliamentary inquiry into FinTech Issues in October 2019, the author has a direct connection with the DSB as outlined on Page 3.

[CDR-API-Stream]

Apologies, I was logged into the wrong account with the previous DSB response.

[CDR-API-Stream]

These three statements combined appear to result in the ADR exposing a revocation endpoint with no network access control available (since source IP of Holder is not known and MTLS is not in use). I reiterate the following statement: "... what consideration has been given for the potential for a denial of service occurring on the computationally expensive Data Recipient revocation endpoint?"

Thanks for the clarification of the concern.

Yes, the Data Recipient exposed end points would be exposed to a DDOS attack in a way that other end points in the regime are not due to the absence of ACL or MTLS mechanisms being in place.

The original position of the standards was that these end points should require MTLS for this (and other reasons). The ADR community requested that this position be changed to allow for easier implementation. Part of this was so that commoditised CDN and WAF mechanisms, that often don't support MTLS, could be adopted.

This is a case of trade off between different controls. If there is a belief that the trade off is inappropriate and that the re-introduction of MTLS (or another mechanism) should be assessed then please raise a change request that the community can respond provide feedback on.

[perlboy]

This is a case of trade off between different controls. If there is a belief that the trade off is inappropriate and that the re-introduction of MTLS (or another mechanism) should be assessed then please raise a change request that the community can respond provide feedback on.

Where were the trade offs documented to begin with?

[perlboy]

See #354.