Decide on B. Access Token Injection with ID Token Replay

[Nat Sakimura]

The security analysis https://arxiv.org/pdf/1901.11520.pdf recommends ID Token from the Token Endpoint to include the hash of the access token for FAPI 1.0.

What should we do for FAPI 2?

[Nat Sakimura]

Discussed on July 27 call.

#526 - Decide on B. Access Token Injection with ID Token Replay

The security analysis https://arxiv.org/pdf/1901.11520.pdf recommends ID Token from the Token Endpoint to include the hash of the access token for FAPI 1.0.

What should we do for FAPI 2? FAPI 2 does not require ID Token which acted as a detached signature.

We need to decide whether we want to rely on server authentication or use a model where all communication is authenticated at the message level. FAPI 2 relies on server authentication so if we need to introduce it on the application level, we will need to reintroduce all the signed request and response of FAPI 1.

Need to decide whether we modify the attacker model or cope with the attack.

[Daniel Fett]

I think the same fixes as for the Cuckoo’s Token Attack apply here - changing sender-constraining keys or sending the issuer’s identity to the resource endpoint (assuming the token endpoint can only be compromised because the issuer URL points to a malicious one).

[Dave Tonge]

Do we need to document this attack? It is specific to ID token replay.

[Joseph Heenan]

This scenario is where the attacker is able to get the honest client to use an incorrect token endpoint (attacker . As Daniel says, it’s similar to the cuckoo’s token attack, but has fewer preconditions, and some of the cuckoo attack mitigations don’t work (e.g. per AS dpop keys doesn’t help, but per session dpop keys would).

In the attacker model, this is “A5 - Read and Tamper with Token Requests and Responses”.

The attacker model states:

Note: When the token endpoint address is obtained from an authoritative source and via a protected channel, e.g., through OAuth Metadata obtained from the honest AS, this attacker is not relevant.

We do fully mandate use of discovery/oauth metadata (now) so the most we need to do is a security consideration that points out something like FAPI clients should be designed such that this mistake is near impossible to make - i.e. they should require the user to provide an issuer value, only accept that when a .well-known/openid-configuration is available under that issue (as opposed to allowing the user to provide the location of the openid configuration - or if they do that, they need to verify the issuer in the openid-configuration matches the one in the url it was retrieved from), and to not provide easy mechanisms for the developer to then override the token endpoint.

[Joseph Heenan]

The cuckoo’s token attack mitigation of using short lived access tokens (combined with refresh tokens) to reduce the time window for the exploit works for this attack too.

[Nat Sakimura]

It is an artefact of not fully protecting the response, so access token lifetime does not fundamentally help.

[Joseph Heenan]

@Nat The attack relies on a leaked access token, so whilst (as you say) short lived access tokens don’t prevent the attack, they do reduce the time window the attacker has to perform an attack.

[Nat Sakimura]

Why not include the AT hash? That fixes this problem and will let us use long-lived access token. That would be way better from a user experience point of view.

[Joseph Heenan]

@Nat Long lived access tokens (depending how long we’re talking) have other problems (if it means a refresh token isn’t issued), like preventing rotation of the key the RP is using for sender constraining.

Including at_hash would require changes in AS and RP, and (as the only id_token in FAPI2 is a backchannel one) we’d also need a clause requiring the RP to validate the id_token signature (which is not normally required when receiving the id_token over a TLS channel). It also only works if we assume the attacker can persuade the RP to change the token endpoint but not the jwks_uri, and doesn’t help when FAPI2 is being used without openid.

‌

[Daniel Fett]

We agreed to close this ticket on today’s call. The attacker A5 required for this attack is not applicable when we trust that metadata is used and correct, as is now mandated by FAPI2. The attacker model is clarified in https://bitbucket.org/openid/fapi/pull-requests/371

[Dave Tonge]

PR merged as per Daniel's comment