use of MTLS

[sebdewet]

Hello,

Spanish Cybersecurity team raised a possible risk in the use of CAMARA API Quality on demand, the first API (in our case) where we are not just “querying” systems but we act over the network to provide a different QoS for a specific user. MasOrange Cybersecurity team would like to introduce MTLS in the use of QoD CAMARA APIs.

MasOrange already use MTLS for the agregator's unboarding, but it's out of CAMARA's scope.

This request would have possible impact on the interoperability between consumers, implies that agregators should have to manage certificates.

I don't think we should extend the use of MTLS to all the camara APIs, but study only for those that could have a higher risks.

There is a risk that aggregators could complain about the use of MTLS to just 1 CAMARA APIs (until others come)

Could this be a CAMARA recommendation or rather be mandatory for a list of APIs considered higher risk ?

[jpengar]

@sebdewet Thank you for bringing this topic for discussion. From Telefónica's perspective, we have some concerns about making mTLS a requirement.

Our main concern is that we might be over-complicating the integration for API consumers without a significant benefit. One of CAMARA's primary goals has always been to simplify the developer experience for using our APIs, and requiring them to handle client-side certificates seems to go against that principle.

We believe our current security measures are already robust. Connections are secured over HTTPS with TLS, which validates the server-side, and we use secure standards like private_key_jwt for client authentication. Adding mTLS on top of this feels like it could be "overkilling" for the scenarios we're addressing.

While we understand the security perspective, we don't currently see a favorable balance between the implementation cost for developers and the added security benefit.

[eric-murray]

Hi @sebdewet

I agree with @jpengar - given that CAMARA already mandate private_key_jwt for client authentication, it is difficult to see what additional security mTLS adds beyond this. Can you share why the MasOrange Cybersecurity team think private_key_jwt is insufficient?

Of course, any API provider can require API consumers to use mTLS with no changes required to the CAMARA specifications, so MasOrange can anyway implement this for the current API specifications if it is a strong requirement.

[gmuratk]

Hi @sebdewet
Is it possible for you to share the 'risks' that the team is hoping to mitigate with respect to such APIs?
Thanks,
cc @murthygorty @RamTMO

[AxelNennker]

OAuth2 Security Best Practices recommend sender-constrained tokens and name DPoP and mutual TLS as ways to implement sender-contrained tokens.

Two methods for sender-constrained access tokens using proof of possession have been defined by the OAuth working group and are in use in practice:

• "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens" [RFC8705]: The approach specified in this) document allows the use of mutual TLS for both client authentication and sender-constrained access tokens. For the purpose of sender-constrained access tokens, the client is identified towards the resource server by the fingerprint of its public key. During the processing of an access token request, the authorization server obtains the client's public key from the TLS stack and associates its fingerprint with the respective access tokens. The resource server in the same way obtains the public key from the TLS stack and compares its fingerprint with the fingerprint associated with the access token.

• "OAuth 2.0 Demonstrating Proof of Possession (DPoP)" [RFC9449]: DPoP outlines an application-level mechanism for sender-constraining access and refresh tokens. It uses proof-of-possession based on a public/private key pair and application-level signing. DPoP can be used with public clients and, in the case of confidential clients, can be combined with any client authentication method.

The CAMARA Security and Interoperability Profile specifies some conditions and rule regarding DPoP.