AS Mix-Up Attack on IAE

[fabian-hk]

@PedramHD and I briefly looked into the PR #589 from a security perspective and found a possible AS Mix-Up attack if the Interactive Authorization EP is used.
We assume the following setting: There is an ecosystem with multiple AS that support the IAE, and some of them can be malicious or have been hacked. In this ecosystem, an honest wallet w uses an attacker AS. In the metadata, the attacker AS specifies the Interactive Authorization EP of an honest AS.

The attack consists of the following steps:
(1) w wants to use the attacker AS, sends an Interactive Authorization Request to the endpoint of the honest AS
(2) The honest AS responds with type = openid4vp_presentation and an auth_session
(3) In the Follow Up Request, w sends a presentation and the auth_session to the Interactive Authorization EP of the honest AS
(4) The honest AS responds with a code
(5) w sends the token request to the attacker AS, i.e., the attacker receives the code together with the matching PKCE verifier
(6) The attacker uses the code and the PKCE verifier on the token EP of the honest AS and receives an access token

This would also be possible through PR #589 in the redirect_to_web case, i.e., the attacker would specify the Interactive Authorization EP and Authorization EP of the honest AS in its metadata. The PR states: “If the Authorization process is not complete when this redirect occurs, the Authorization Server returns a response with the auth_session parameter.” The way we interpret this is that this response is not a normal authorization response, so recommendations regarding iss response parameters from the Security BCP would not apply.

[GarethCOliver]

Attack makes sense. It seems like the Mix-Up Defense via Issuer Identification would work here in the same way as it does for authorization response? (i.e. return iss from IAE and require it to be checked).

[jogu]

Thanks Fabian!

For the IAR endpoint in general, The recommendation to use FAPI2 (and hence the iss parameter in the response) I believe mitigates this.

In HAIP, using FAPI2 moves from a recommendation to a 'must' (assuming openid/OpenID4VC-HAIP#214 is merged).

[fabian-hk]

We believe returning the iss parameter with every response from the IAE will mitigate this particular attack, but without a thorough formal security analysis, we cannot say whether this prevents all possible variations of such an attack.

[Sakurann]

URL to how this is addressed in usual OAuth https://datatracker.ietf.org/doc/html/rfc9207

[jogu]

Rereading this again, I'm not sure the attack is really possible in a meaningful way as the wallet attestation would have the aud of attacker's AS as hence the attacker can't replay it to the honest AS. I'm having doubts that the extra complexity of "iss" makes sense for the "openid4vp_presentation" case? [I think it would help with public clients or for non-asymmetric client authentication, but I think both of those cases also have more pressing security weaknesses than mixup attacks.]

It does make sense for "redirect_to_web" case I believe and we need text about that. And I think we don't say (but should say) that auth_session needs to be bound to the client_id and (if applicable) client instance.

[jogu]

To expand on my previous comment, I believe when using wallet attestations for client authentication the attack will fail at step 1 - Aud in the client authentication will be the attackers issuer value, and the honest AS won’t accept it

[jogu]

Discussed on today's WG call: seemed to be a consensus that wallet attestations do prevent the attack, but use of iss may still be a mitigation that could be used in other cases. We need text in security considerations so that people extending the spec are aware that need to pick one of the mechanisms.

For the redirect_to_web flow currently in the spec we're good. For the #589 we'd need to add extra text requiring similar behaviour for iss.

Consensus that we should define iss for the IAR endpoint calls as Fabian had suggested and do that always, even in the cases where wallet attestations likely already prevent the attack.

[jogu]

Further discussion about what we do with IAR in 1.0:

It's feeling a bit too rush and not feeling good enough to ship yet, could be a footgun. Many people don't have a good feeling about it.

1.1 could take a long time and delay this feature. Could put it into a separate spec. This could mean we need a HAIP 1.1 that refers to VCI 1.1 or the next spec. We need to be careful about the language in HAIP that currently mandates PAR and hence precludes the use of IAR.

Conclusions:

1. Agreed we'd create PR to remove IAE, publish a new draft of VCI and send out the vote announcement tomorrow.

2. We should publish the IAE draft text somewhere so people can continue to review / implement it. Editors/chairs will find a solution.