IETF Logo Mail Archive

Re: [OAUTH-WG] Implementation questions around refresh token rotation

David Waite <david@alkaline-solutions.com> Mon, 12 October 2020 09:54 UTC

Return-Path: <david@alkaline-solutions.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620A03A13CB for <oauth@ietfa.amsl.com>; Mon, 12 Oct 2020 02:54:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, UNPARSEABLE_RELAY=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=alkaline-solutions.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9C7YIJHUONCZ for <oauth@ietfa.amsl.com>; Mon, 12 Oct 2020 02:54:31 -0700 (PDT)
Received: from caesium6.alkaline.solutions (caesium6.alkaline.solutions [157.230.133.164]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8FA23A13CA for <oauth@ietf.org>; Mon, 12 Oct 2020 02:54:31 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by caesium6.alkaline.solutions (Postfix) with ESMTPA id 402BA20473B; Mon, 12 Oct 2020 09:54:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1602496469; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2POAzcSIPqcBXzQW94MNp3NRYI4KzXDK9LmU5y6NktY=; b=pOO6ZMuFP5q46tPqpdvtzqifhMafEKrS854r2/OAwTZc41Mx8WxoFC2gOqA0CgXj6dNHd0 9xoK3D91mjEhUlXMlGl9RkTc4ZM9M5ETJEjnC2jYKCBN1yklNvI7yEyqeA8ndN1N06mVIk oJOuzB6ptyOF3NzHK+yLI2mDHyUHN8Y=
From: David Waite <david@alkaline-solutions.com>
Message-Id: <AE670A80-E622-4244-B1E8-15A990D644D4@alkaline-solutions.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_36892377-4E91-49BE-A93E-34DA885E33E5"
Mime-Version: 1.0
Date: Mon, 12 Oct 2020 03:54:26 -0600
In-Reply-To: <81E51F61-E093-4467-BBDB-5FC1CF593598@lodderstedt.net>
Cc: Dave Tonge <dave.tonge@momentumft.co.uk>, Jeff Craig <jeffcraig=40google.com@dmarc.ietf.org>, vittorio.bertocci=40auth0.com@dmarc.ietf.org, OAuth WG <oauth@ietf.org>
To: Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>
References: <CAP-T6TRDeBqT9K=QTUr_xKnkMGAT1gCtr0W2=ejBCk0vhk0sdw@mail.gmail.com> <81E51F61-E093-4467-BBDB-5FC1CF593598@lodderstedt.net>
Authentication-Results: caesium6.alkaline.solutions; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com
X-Spamd-Bar: /
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/FV_XS32fszO_n31iuWLhHZwL0DY>
Subject: Re: [OAUTH-WG] Implementation questions around refresh token rotation
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: Mon, 12 Oct 2020 09:54:33 -0000

An AS may decide refresh token rotation is useful for other reasons (such as if the token is an encrypted value and the AS cluster does key rotation), or may decide to rotate all tokens for consistency.

Eventually best practices may indicate sender constrained tokens for public clients. At that point, refresh rotation may not be security practice but could still be something an AS does as part of its own design. And an AS may elect to do this often so that clients fail (and correct their logic) faster.

-DW

> On Oct 12, 2020, at 03:15, Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org> wrote:
> 
>> 
>> Am 12.10.2020 um 09:04 schrieb Dave Tonge <dave.tonge@momentumft.co.uk <mailto:dave.tonge@momentumft.co.uk>>:
>> 
>> 
>> Hi Neil
>> 
>>  > refresh token rotation is better thought of as providing protection against insecure token storage on the client
>> 
>> I agree with your reasoning - and that was more the intent of what I said. We've seen refresh token rotation used for confidential clients that have secure storage (i.e. are run in a data center not on a mobile device) and it has caused problems with zero additional security benefits. 
> 
> Those are good examples of why refresh token rotation should not be used if there are better ways available to protect refresh tokens from replay. Client authentication or sender constrained refresh tokens are the better choice.

v2.23.0 | Report a Bug | By Email