CIBA Privacy

[AxelNennker]

Problem description
An attacker, e.g misbehaving API Consumer or misbehaving Aggregator or somebody who stole the API Consumer's credentials, can send CIBA requests with arbitrary login_hints.
CAMARA APIs Access and User Consent Management "validates the user identifier" in step 2 and then in step 3 checks the legal basis for the purpose and then in step 4 checks "if consent is granted".

Now the attack: if the AZ responds immediately responds then the attacker knows that the User did either granted consent or did not opt-out for this combination of request parameters - consent is not needed. So, the AZ is revealing personal data about the User (whether they consented, opted-out, ...)

The attacker with valid Credentials can create CIBA Authentication Requests and iterate through many MSISDNs.

Let's say the attacker bought some MSISDNs from a databreach and wants to prepare an attack. The attacker can now check the consent-needed-status for an API and then either trick the users into opting-out of that API or focus their attack on Users who opted-out of some API, because attacks on Users who opted-out are more likely to succeed.

In the example attack the attacker does not (immediately) get an access token for an API, but the attacker gains personal data(the fact that he has opted out) about the User. We are violating the User's privacy.

Variant of this privacy-violating attack: If the CIBA Authentication Request is not signed, the Aggregator can manipulate the login_hint value and get personal data about a different User Identifier (MSISDN). The MNO has no protection against a misbehaving Aggregator.

OIDC Authorization Code Flow and CIBA add User authentication to OAuth2, but in the current CAMARA CIBA flow there is no User authentication if consent is not needed. The CIBA flow as shown in CAMARA APIs Access and User Consent Management seems to be more like a two-legged flow because the current CIBA flow does not involve any User authentication.

[MarkCornall]

would you not also need to have stolen credentials to query the operator? Is that not limited to the scope of the API that access was previously granted access to for a nominated developer and application in the application onboarding?

[HuubAppelboom]

@AxelNennker You seem to be worried that whether a user has provided consent or not is a privacy sensitive matter. However, if you do a Authorization Code Flow, the API Consumer will always learn whether an end user has provided consent yes or no.
How do you want to prevent this? Ask the user at the same time whether the denial of his consent can be shared with the API Consumer ??

In general, I think an application builder can always ask the OS whether the user has given consent or not for example for sharing his location, his microphone, etc. There is nothing wrong about this, if you ask me.

[AxelNennker]

@AxelNennker You seem to be worried that whether a user has provided consent or not is a privacy sensitive matter. However, if you do a Authorization Code Flow, the API Consumer will always learn whether an end user has provided consent yes or no. How do you want to prevent this? Ask the user at the same time whether the denial of his consent can be shared with the API Consumer ??

In general, I think an application builder can always ask the OS whether the user has given consent or not for example for sharing his location, his microphone, etc. There is nothing wrong about this, if you ask me.

The difference is that with the current checking of consent or login-status in CIBA we trust the API Consumer.
In Authorization Code Flow the API Provider's Authorization Server can do network-based authentication and in some cases that is enough that we are "sure enough" that subscriber equals end-user (data-subject). If the Authorization Server is not "sure enough" then the Authorization Server cannot determine the consent status of the end-user and SHOULD proceed with end-user authentication and end-user consent collection if there is no "prompt=none" in the request.
With CIBA the Authorization Server would rely on the user identifier from the Authorization Reqest (login_hint) which even the API Consumer does not know whether that user identifier belongs to the end-user sitting in front of the e.g. laptop.
CIBA is an authentication protocol to created to establish the end-user identity and their consent. So, neither the API Consumer nor the API Provider's Authorization Server can rely on the value of login_hint. If the Authorization Server cannot rely on login_hint's value, the user identifier, then the Authorization Server cannot check the consent status. Relying on the user identifier would defeat the purpose of CIBA which is to authenticate the user by sending a message to the authentication device.

[HuubAppelboom]

@AxelNennker On the other hand, if you look at the current Mobile Connect implementations, a bad actor may be doing the same thing with SIM Swap information, just iterating over many MSISDN's etc.

What can potentially solve this is the following:

• For use cases where user consent is required, use always the 3 legged flows (CIBA or Front End Flow).
• With the CIBA flow and user consent, do not use MSISDN anymore as login hint. In stead use a unique token or identifier which was issued to the API Consumer in a previous Front End Flow (the first time the user had to give consent). This should be an identifier which can not be easily enumerated. Remember the PCR used under Mobile Connect ? This may just do it. Or a long lived token.
• And when the end user withdraws his/her consent in a selfcare portal, simply give an error in the CIBA Flow.

For use cases where user consent does not play a role, use the Client Credential flow. Is also much faster, and for cases where legitimate interest is applicable, this works fine today.

[AxelNennker]

@AxelNennker On the other hand, if you look at the current Mobile Connect implementations, a bad actor may be doing the same thing with SIM Swap information, just iterating over many MSISDN's etc.

What can potentially solve this is the following:

* For use cases where user consent is required, use always the 3 legged flows (CIBA or Front End Flow).

* With the CIBA flow and user consent, do not use MSISDN anymore as login hint.  In stead use a unique token or identifier which was issued to the API Consumer in a previous Front End Flow (the first time the user had to give consent).  This should be an identifier which can not be easily enumerated. Remember the PCR used under Mobile Connect ?  This may just do it. Or a long lived token.

* And when the end user withdraws his/her consent in a selfcare portal, simply give an error in the CIBA Flow.

For use cases where user consent does not play a role, use the Client Credential flow. Is also much faster, and for cases where legitimate interest is applicable, this works fine today.

I think using login_hint_token or id_token_hint with CIBA is a way how the API Consumer can proof that they got an access token in the past and who the User is. E.g. the sub value in the id_token is unique for the User.

I would suggest to use id_token_hint because id_token is sufficiently defined, while login_hint_token is more of a placeholder in the spec saying "do whatever you want and have agreed upon between client and CIBA authorization server".

I think MSISDN as a user identifier in CIBA is problematic if no message is sent to the authentication device.
In Germany and maybe in other markets as well, using ipport as a user identifier is even more regulated.

I invite everybody to propose text for the associated PR and maybe add text to the Security and Interoperability Profile to allow id_token_hint.

[HuubAppelboom]

@AxelNennker id_token_hint may indeed be an adequate solution to prevent that an attacker will go over a whole batch of msisdns and discover the status of whether consent is active or not. But this only makes sense for API's for which consent is being used, as an extra and optional security measure.

There are also API's like Sim Swap which are usually offered on basis of legimate interest, and for which no consent is needed or is useful. I doubt there will be much interest with attackers to harvest this kind of data on a large scale. If a id_token_hint becames a mandatory option, it also implies that you will always need to execute at least once an authorization code flow for that msisdn, which may be very impractical to do. Many customers still use SMS 2FA, and they don't have an authorization code flow to harvest these id_tokens. So I don't think a id_token_hint should become mandatory for all CIBA flows, because this will make things much more complex for those API Consumers who use the APIs as intended.

[AxelNennker]

@AxelNennker id_token_hint may indeed be an adequate solution to prevent that an attacker will go over a whole batch of msisdns and discover the status of whether consent is active or not. But this only makes sense for API's for which consent is being used, as an extra and optional security measure.

There are also API's like Sim Swap which are usually offered on basis of legimate interest, and for which no consent is needed or is useful. I doubt there will be much interest with attackers to harvest this kind of data on a large scale. If a id_token_hint becames a mandatory option, it also implies that you will always need to execute at least once an authorization code flow for that msisdn, which may be very impractical to do. Many customers still use SMS 2FA, and they don't have an authorization code flow to harvest these id_tokens. So I don't think a id_token_hint should become mandatory for all CIBA flows, because this will make things much more complex for those API Consumers who use the APIs as intended.

If using a client credentials is legal then API Consumers can use it to retrieve a valid access token.

I think API Consumers should not use CIBA as a two-legged flow.

As always, OIDC and CIBA are here to help. This is not about making id_token_hint mandatory.

Using id_token_hint provides a way for the API Consumer to tell the API Provider: "Look, I got a proper three-legged id_token in the past, please consider this hint in the current flow".
I think id_token_hint is "better" than "login_hint" in that the id_token is signed by the API provider's Authorization Server, so, if the id_token is presented through the id_token_hint, then the API Provider can check its own signature and be sure that the data in the id_token is unmodified and then take the "sub" to identify the User/"API Subject".

Yes, if we allow id_token_hint, then this mandates that all API Providers' Authorization Server MUST support id_token_hint.

But again, if client credentials flow is legal in the API Consumer's jurisdiction for this use case and purpose, then please use client credentials and not CIBA without "authentication". Validating the id_token becomes the User authentication method.

That is similar to cookies in Authorization Code Flow which is redirect based and might use cookies from the end-user's browser or webview to determine the end-user's login-status.

[AxelNennker]

@AxelNennker On the other hand, if you look at the current Mobile Connect implementations, a bad actor may be doing the same thing with SIM Swap information, just iterating over many MSISDN's etc.

What can potentially solve this is the following:

* For use cases where user consent is required, use always the 3 legged flows (CIBA or Front End Flow).

* With the CIBA flow and user consent, do not use MSISDN anymore as login hint.  In stead use a unique token or identifier which was issued to the API Consumer in a previous Front End Flow (the first time the user had to give consent).  This should be an identifier which can not be easily enumerated. Remember the PCR used under Mobile Connect ?  This may just do it. Or a long lived token.

* And when the end user withdraws his/her consent in a selfcare portal, simply give an error in the CIBA Flow.

For use cases where user consent does not play a role, use the Client Credential flow. Is also much faster, and for cases where legitimate interest is applicable, this works fine today.

@HuubAppelboom I would add that the API Consumer SHOULD use signed requests and that an aggregator MUST forward the signed request object, so that the API Producer is sure the request is unmodified and also knows which API Consumer created it.