Re: [OAUTH-WG] [EXTERNAL] Rotating RTs and grace periods

[Aaron Parecki <[e-mail]>]

The grace period is not about the refresh token lifetime, it's specifically
about whether what would be a single-use refresh token can be used more
than one time within a short window of the first use.

Okta supports a configurable grace period per application that the customer
can set, anywhere from 0 to 60 seconds.

Personally I also agree with Neil that a grace period is not a good idea
from the security aspect, but I do also see that we have a lot of customers
who ask for this feature due to things like flaky mobile networks.

I like the suggested text from Neil. I assume this would go into the
Security BCP as well as OAuth 2.1?

Aaron


On Tue, Nov 2, 2021 at 7:09 AM Pieter Kasselman <pieter.kasselman=
[e-mail]> wrote:

> Neil
>
>
>
> Is the goal to accommodate network latency or clock drift? It would be
> helpful to include reasons for why a grace period should be considered if
> it is allowed.
>
>
>
> Without knowing the reasons for the grace period it is not clear why a
> grace period is a better solution than just extending the expiry time by a
> set time (60 seconds in your example) and having the client present the
> token a little earlier.
>
>
>
> If grace periods are allowed, it may be worth considering adding
> additional mitigations against replay. For example, a grace period may be
> allowed if the refresh token is sender constrained with DPoP so there is at
> least some assurances that the request is originating from the sender
> (especially if the nonce option is used with DPoP).
>
>
>
> I would worry about adding more complexity and less predictability by
> adding grace periods though (e.g. by looking at a refresh token, will you
> be able to tell if it can still be used or not), but your point that
> implementors may solve for it in other less predictable ways raises a valid
> point.
>
>
>
> Cheers
>
>
>
> Pieter
>
>
>
> *From:* OAuth <[e-mail]> *On Behalf Of *Neil Madden
> *Sent:* Tuesday 2 November 2021 10:29
> *To:* oauth <[e-mail]>
> *Subject:* [EXTERNAL] [OAUTH-WG] Rotating RTs and grace periods
>
>
>
> Hi all,
>
>
>
> There was a previous discussion on whether to allow a grace period during
> refresh token rotation, allowing the client to retry a refresh if the
> response fails to be received due to some transient network issue/timeout
> [1]. Vittorio mentioned that Auth0 already implement such a grace period.
> We (ForgeRock) currently do not, but we do periodically receive requests to
> support this. The current security BCP draft is silent on whether
> implementing such a grace period is a good idea, but I think we should add
> some guidance here one way or another.
>
>
>
> My own opinion is that a grace period is not a good idea, and if it is to
> be supported as an option then it should be kept as short as possible. The
> reason (as I mentioned in the previous thread) is that it is quite easy for
> an attacker to observe when a legitimate client performs a refresh flow and
> so can easily sneak in their own request afterwards within the grace
> period. There are several reasons why it is easy for an attacker to observe
> this:
>
>
>
> - RT rotation is primarily intended for public clients, such as mobile
> apps and SPAs. These clients are geographically distributed across the
> internet, and so there is a good chance that the attacker is able to
> observe the network traffic of at least some of these client instances.
>
> - The refresh flow is typically the only request that the client makes
> directly to the AS after initial authorization, so despite the traffic
> being encrypted it is very easy for an observer to determine that the
> client is performing a refresh whenever it makes any connection to the AS.
>
> - As well as observing the request itself, an attacker may be able to
> observe the DNS lookup for the AS hostname instead, which is even more
> likely to be observable and also in plaintext most of the time.
>
> - An attacker in a position to steal RTs from e.g. localStorage, is
> probably also in a good position to either observe when the legitimate
> client refreshes or to actually force it to refresh early (e.g., by
> deleting the corresponding AT from the same storage).
>
>
>
> I know some people argue that a grace period is a reasonable trade-off
> between security and usability. But I think that this kind of attack would
> be quite easy to carry out in practice for the reasons I suggest above, so
> I think the security actually degrades extremely quickly if you allow a
> grace period of any reasonable length.
>
>
>
> On the other hand, if we discourage this entirely then people may use
> dubious workarounds instead (e.g., one proposal I’ve seen was to use an ID
> token with the JWT Bearer grant, effectively turning the ID Token into an
> ad-hoc RT with much fewer protections).
>
>
>
> As a strawman, what would people think of wording like the following:
>
>
>
> ---
>
> The AS MAY allow the original RT to be replayed for a short grace period
> to allow the client to recover if the response is not received due to a
> network problem or other transient issue. However, implementors should be
> aware that an attacker may be able to easily observe when the legitimate
> client makes a refresh request to the AS and so time their use of a stolen
> RT to occur within the grace period. Any grace period MUST be kept as short
> as possible, and MUST NOT exceed 60 seconds. Clients should prefer
> sender-constrained refresh tokens if recovery from network issues is a
> priority.
>
> —
>
>
>
> (The 60 seconds limit here is based on Auth0’s grace period).
>
>
>
> [1]:
> https://mailarchive.ietf.org/arch/msg/oauth/WXwKxQM2poW7bqOOGGp4POYolFk/
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Foauth%2FWXwKxQM2poW7bqOOGGp4POYolFk%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cbdb0969234774ba6f87608d99deba06c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637714457664531224%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CDskCHwXxJxGdmudTW33gUT5f3%2B835uZDxyNEmKkiFc%3D&reserved=0>
>
>
>
>
> Kind regards,
>
>
>
> Neil
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>