[OAUTH-WG] Rotating RTs and grace periods

Neil Madden <neil.madden@forgerock.com> Tue, 02 November 2021 10:29 UTC

Return-Path: <neil.madden@forgerock.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 885093A109A for <oauth@ietfa.amsl.com>; Tue, 2 Nov 2021 03:29:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 0bAKUN3UrUhQ for <oauth@ietfa.amsl.com>; Tue, 2 Nov 2021 03:28:58 -0700 (PDT)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A83A83A1097 for <oauth@ietf.org>; Tue, 2 Nov 2021 03:28:58 -0700 (PDT)
Received: by mail-wm1-x331.google.com with SMTP id f7-20020a1c1f07000000b0032ee11917ceso1718732wmf.0 for <oauth@ietf.org>; Tue, 02 Nov 2021 03:28:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:message-id:date:to; bh=tJUAucdslUgu/SAITQwaYklNenACpymCIrKHcl2HOQM=; b=KPBhOrz895d/z7nqhWTI3USgDVo0K/cxUch3+Q18N6oYBpHihmZd+KZZgxsooizjTe BrEA8QoAOK4RWkSd4kUt++yHcmmbOreeEWZflDMiAdQXMifUiF+pOCHhkavS3romB7iq kjMJ9DFeX2UzNDmAf3466Dz4Qj5dqQYf6yrnM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=tJUAucdslUgu/SAITQwaYklNenACpymCIrKHcl2HOQM=; b=Hx22ivWTmH+Y3nMWMdpPZg5tvvXCSvCzChsxH8VO5U1b0ZCbCHzEDPQutBtGVU+rlQ KPXfSXanr3SxkBcYG+uX35FxAhWqCq9UyR4hZYwtswP96po4mq0qeWwQ2hgTr2qhyJa1 Nvy36hrIku2TOnLW7TpSAgKNwE6AnJPTmIGHAVLqaK8yXAd0TOCNlc3Z9aTICuVuOP/k fnGTBteo9cjPZX5GxKUBXn/18w/LxuaDit0sEhvLdZOajW78KX2Vgw4IjflLNG3nSdl4 g2IMNVDZ9k8ZTDEq7oec+eiO6RNXEWC+Lx4b93hF6o0Dd/g2qRyqg4PVymYThWfRvQO3 Kqdg==
X-Gm-Message-State: AOAM531aemgOAPgbGZzYTHZ/HA78hs1vWmyOja0lOPNva9G4tx+Q+YJf 5du1sQVC0UZAdrN9hKZTcDGb52f4zRUYMGKnOeOZ7/faUppUe1vHOXjsB74pk8h63bbhEXakzI/ 93I6djZmDHmp2vl/uvnr0g8qLOtr34MmBPbK6FcuKEteM2Nz/uat4iHnG7lC/QuseQA==
X-Google-Smtp-Source: ABdhPJzt37zZPL89JJ3d4/MnZXr8hF4oQh6MKnxgnWh99zSCgGbHmgsSYHbE0ErqpuyijFQnnqqzxg==
X-Received: by 2002:a05:600c:4108:: with SMTP id j8mr5800721wmi.139.1635848934781; Tue, 02 Nov 2021 03:28:54 -0700 (PDT)
Received: from [] (78-33-22-162.static.enta.net. []) by smtp.gmail.com with ESMTPSA id a4sm834421wmg.10.2021. for <oauth@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Nov 2021 03:28:54 -0700 (PDT)
From: Neil Madden <neil.madden@forgerock.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DD9787C9-ECDA-475A-98D9-3D2E27CF4499"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Message-Id: <76A1A85D-2DDC-4544-92B0-1723D3303408@forgerock.com>
Date: Tue, 02 Nov 2021 10:28:53 +0000
To: oauth <oauth@ietf.org>
X-Mailer: Apple Mail (2.3608.
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/X2S1otBruLSligdwp6vPs_WyZzo>
Subject: [OAUTH-WG] Rotating RTs and grace periods
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Nov 2021 10:29:04 -0000

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://mailarchive.ietf.org/arch/msg/oauth/WXwKxQM2poW7bqOOGGp4POYolFk/> 

Kind regards,