Simplifying the usage of FAPI-CIBA and FAPI 2 profiles together

[Dima Postnikov]

1. FAPI security shoiuld at least meantion CIBA as a valid alternative to Auth Code flow

5.3.1. Requirements for Authorization Servers

5.3.1.1. General Requirements

5.3.1.2. Authorization Code Flow

5.3.1.3. Client Initiated backchannel flow

refer tol FAPI-CIBA spec

5.3.1.4. Returning Authenticated User's Identifier

5.3.2. Requirements for Clients

5.3.2.1. General Requirements

5.3.2.2. Authorization Code Flow

5.3.2.3. Client Initiated backchannel flow

refer tol FAPI-CIBA spec

‌

2. We should make it clear that the same authentication and request signing requirements apply to both PAR and CIBA auth request endpoints. and take that out of the CIBA spec.

‌

[Nicholas Irving]

One of the challenges we have with CIBA is that it requires a) a hint to identify the account and b) requires notification support on the non consumer device.

‌

With a) this can lead to phishing sites replication the look of a providers hunt gathering site and push them through a flow to gather further details such as credentials.

With b) there is a cost to push to the non consumer device such as SMS or push notification. Some consumers may disable the notification and therefore cannot use the service

We propose using a device code like flow, where a QR Code is presented and scanned by a device and does not opens the app (or webpage) to collect the details. By enforcing an app to read the details of the QR code we can better control the experience and aim to defeat a phishing attack.

bankId follows this process to move a user from web to app.

By having the user open the app and using the inbuilt scanning capability the user will not be facing notification bombing or fatigue as it becomes their choice to perform the operation.

Yes it could still be exploited, but it reduces the initial attack surface as no personal details are required to start the process.

The device code flow is well established in streaming services so it is an experience a large number of people will know. It also eliminates the need to collect details up front

We admit it is not fool proof, but what is? The less details a scammer /Phisher has is good in our eyes.

‌

[Nicholas Irving]

https://www.bankid.com/utvecklare/guider/teknisk-integrationsguide/qrkoder for bankId details.

[Dima Postnikov]

@Nicholas Irving this issue is focusing on linking 2 FAPI specification together (FAPI 2 + FAPI-CIBA) and removing repeating content.

Some of your comments might be already covered or will need to be covered here: https://datatracker.ietf.org/doc/draft-ietf-oauth-cross-device-security/

@Filip Skokan @Daniel Fett @Pieter Kasselman

And some comments might need to be raised separately for FAPI-CIBA specification.

‌

[Nicholas Irving]

Sorry I read this

|FAPI security shoiuld at least meantion CIBA as a valid alternative to Auth Code flow

[Pieter Kasselman]

@Nicholas Irving there has been numerous exploits against the Device Authorization Grant (aka device code flow) out in the wild. In some ways it is even more vulnerable to cross-device consent phishing and other social engineering attacks than CIBA. I would strongly suggest reading sections 4.1 for the kind of attacks we see against the device authorization grant and other similar protocols. Also take a look at the protocol selection guidance (section 5) and mitigations in Section 6 https://datatracker.ietf.org/doc/draft-ietf-oauth-cross-device-security/ - none of these fully mitigate the risks, but by combining a few of them, you may be able tor educe the overall risk.

[Nicholas Irving]

Thanks @Peter Kassenaar for the page. The difference is between CIBA and Device Flow I am presenting is that no hint is collected with Device Flow, it cuts out the notification channel direct to the Authorisation Device by allowing the identity to select their trusted application to perform the session transfer. This QR Code is secured using a signing or encryption key trusted by the application and the response back to the authorisation service is signed with a device key established during an earlier registration process. Again like the flows used by CIBA, but it removes the notification fatigue issue as there is no pop up during its use.

You could say both methods introduce the same risk as the authorisation device could be compromised with a malicious app that responds to notifications or QR Code reads, but the important piece is the securing of the session transfer response that makes it hard for an attacker to establish the session transfer themselves.

It's the CIBA approach of collecting a hint and notifying is what I am trying to avoid

In your examples you leave out how CIBA hint information is collected and I feel that needs to be upfront in those flows so as to avoid interpretation on how to establish an session that an attacker can exploit.

The flow OP is trying to address I believe is to address a Web to App issue where an Authorisation Server does not want the transaction to occur over a web channel, instead transfering them to a trusted mobile application, but removing the cost of a notification in the web channel.

Yes QR codes are bad, because they can push to a malicious app or website if you scan outside of the trusted App, but the same is true of CIBA. It just removes the hint collection from the flow.

‌

[Nicholas Irving]

For clarification this is to create an identity in the Resource Provider by collecting attributes from an Identity or Attribute Provider, where the identity selects an Identity Provider, such as a bank, from a list provided by a trusted provider such as a Digital Id government service.

For example myGovId in Australia does a Device Code Flow by first collecting an email address and then presenting a 4 digit pin that needs to be entered into the myGovId application that then establish trust to send back to the Resource Provider. I am trying to eliminate that initial collection of data aka the hint from that flow.

Once established I don't care how the RP collects sessions on their identity as the IDP is no longer involved in that flow, as the RP already has the details provided.

[Dave Tonge]

We discussed on the call today, and those on the call were not in favour of this change.