Make pre-authorized code flow optional?

[Sakurann]

During the OAuth Security Workshop, Fabian's formal analysis highlighted that it is very hard to ensure the pre-auth code gets into the intended wallet. even when the PIN is used, if the QRcode with pre-auth code is scanned by a malicious wallet, chances are high that the user will type in the correct PIN received via a separate channel in the malicious wallet.
At the same time, I am reluctant to remove this flow, because it is important for the issuance when user authentication is done in-person in the government office.

[paulbastian]

This would likely be countered by client attestation, however client attestation is probably not required but recommended?

[asharif1990]

I agree with Kristina and I think in the high assurance profile there is no place for pre-auth code flow. Furthermore, as it is mentioned in the OIDF workshop for the eIDAS expert group the pre-auth code flow is usable for scenarios that demand a lower level of security, and seems strange to me to see it in HAIP. We already shared our concerns regarding the usage of this flow here.

[tlodderstedt]

Is this an issue with pre-authz code or cross device in general? I'm asking since cross device could be done with authz code flow, too. Not sure, however, this is more secure in any way.

[asharif1990]

Is this an issue with pre-authz code or cross device in general? I'm asking since cross device could be done with authz code flow, too. Not sure, however, this is more secure in any way.

I agree that in the case of cross-device flow, the same attack vector is applicable for the authz code flow as well. However, in the case of the same device flow, another big problem with the pre-auth code flow is PIN phishing, while in the case of authz code flow is not applicable and we have PKCE to avoid the code injection/replay attacks. In the case of cross-device, the best we can do is integration available BCPs in the cross-device draft.

[tlodderstedt]

I have checked back with Fabian. My conclusion: this issue always exists, if there is state from before the credential offer that is conveyed into the issuance process. So even if the authz code is used, if it is used in conjunction with issuer_state, we have the same problem.

[fabian-hk]

@paulbastian I would like to point out that wallet attestation does not prevent the attack on the pre-authorized code flow, because the attacker can use an unmodified wallet on a device under his control to exchange the pre-authorized code for a credential.

[tlodderstedt]

@fabian-hk do you think that attack won't work with authorization code and issuer_state?

[fabian-hk]

Let us clarify what exactly we are talking about here. The attack I discovered during my formal security analysis assumes the following things:

1. A malicious application is installed on the user's device
2. The user selects the malicious application to process the credential offer

After selecting the malicious app, the attacker can also ask for the user pin, which is not suspicious because the wallet is supposed to do that.
As mentioned above, the attack works even if wallet attestation is used, because the attacker injects the credential offer into an unmodified wallet.
You can see the procedure of the attack in this sequence diagram.
This attack works whenever there is a state transfer from the issuer to the wallet application in the credential offer, and there is no further authentication of the user to the issuer after receiving the credential offer.
@tlodderstedt To answer your question: The attack would also work with the issuer_state if there is no user authentication at the issuer after the authorization request is redirected to the issuer's authentication endpoint.

[peppelinux]

I fully agree that pre-authorized code flow should be optional in the HAIP

here the motivations
italia/eudi-wallet-it-docs#172