Rotation of Refresh token - Compromised client highlighted by AU - CDR Independent review.

[Anoop Saxena]

Team,

I think we have reviewed this topic in the past - “Rotation of Refresh token”. ( https://bitbucket.org/openid/fapi/issues/456/proposal-should-we-remove-support-for) and landed on decision not support refresh token rotation - https://bitbucket.org/openid/fapi/pull-requests/306/add-refresh-token-rotation-clause-and-note

‌

There is a independent analysis done in AU CDR and report is shared https://github.com/ConsumerDataStandardsAustralia/standards/issues/258 . In the report, see 7.2 & 7.3 on “Token Rotation” on page 36, 37 and 38.

Few call-outs:

1. CONCERN

   1. Replay attacks remains in the case of client being compromised
   2. Longer window of upto 12 month life of refresh token is risk.

2. CONSIDERATION

   1. Consider overlap of new and old for while to minimized until new one is used.
   2. Suggestion for further discussion 26. Recommend that FAPI re-evaluates
      the security implications of not performing refresh token rotation if a con?dential client is compromised.
   3. Recommendation 27. If no changes are forthcoming to FAPI, the Data Standards should be consistent with it and only discourage but not prohibit token rotation

‌

Purpose of this ticket to address these concerns and evaluate consideration working with WU CDR team.

‌

‌

‌

[Joseph Heenan]

For FAPI2, we settled on the text:

shall not use refresh token rotation unless, in the case a response with a new refresh token is not received and stored by the client, retrying the request (with the previous refresh token) will succeed.

‌

so I think we’re probably fine?

As an aside, I’m not sure how much I agree with the text in the report. I’m pretty sure it’s a base assumption of our security model (and OAuth2 in general) that the client isn’t compromised. The attack assumed seems to be a pretty constrained set of circumstances, where:

1. the client's private key (which really should be in a HSM and hence not extractable) is obtained by the attacker
2. the attacker doesn’t have ongoing access to the legitimate client (so can’t obtain any new refresh tokens issued to the real client)
3. the compromise wasn’t discovered (and hence the client’s private key wasn’t rotated to invalidate the stolen key)
4. the legitimate client would consider a failure when using a refresh token as an indication of possible compromise of the client credentials

(There’s possibly a slightly wider attack in the general context of FAPI, e.g. '1' could be achieved for a client using private_key_jwt with the key in a HSM by instead pre-generating of client authentication assertions; extra requirements in CDR like requiring MTLS [in addition to private_key_jwt] and I think only allowing on active refresh token per client make the attack harder in CDR.)

[Brian Campbell]

Concur w/ Joseph

[Anoop Saxena]

We will keep this ticket open and wait for update from Mark V (AU team) - recording perspective then we can close it.. Estimate time to get this final comments from AU team in 3-4 weeks.

[Nat Sakimura]

@Anoop, could you close it?

[Anoop Saxena]

Will close based Joseph's explanation and the AU ticket did not have any specific call out at this time