IETF Logo Mail Archive

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

Torsten Lodderstedt <torsten@lodderstedt.net> Tue, 20 November 2018 19:39 UTC

Return-Path: <torsten@lodderstedt.net>
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 488BD130DCF for <oauth@ietfa.amsl.com>; Tue, 20 Nov 2018 11:39:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 jVwQTGMYImtP for <oauth@ietfa.amsl.com>; Tue, 20 Nov 2018 11:39:20 -0800 (PST)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5D4312D4E9 for <oauth@ietf.org>; Tue, 20 Nov 2018 11:39:19 -0800 (PST)
Received: from [91.13.153.47] (helo=[192.168.71.123]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from <torsten@lodderstedt.net>) id 1gPBrh-0005Fc-D0; Tue, 20 Nov 2018 20:39:17 +0100
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-Id: <2740EE7E-0290-400C-80DE-746C7BC1240C@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_262CA8AE-620A-4613-B079-E62645B1B011"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Tue, 20 Nov 2018 20:39:16 +0100
In-Reply-To: <A31F247F-8537-4FC5-AC64-A85927A68D3F@manicode.com>
Cc: Hans Zandbelt <hans.zandbelt@zmartzone.eu>, "oauth@ietf.org" <oauth@ietf.org>
To: Jim Manico <jim@manicode.com>
References: <VI1PR0801MB211299BED6B61582DC33B873FACB0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <CAGBSGjqHKVveZor-oKUWzsQ0Rg5Fk_d2dns_eQFqfvXJynyQaQ@mail.gmail.com> <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <915498670.1574190.1542373190714@mail.yahoo.com> <A96E37F1-B09D-41C9-9F5F-DA7C133B00E2@lodderstedt.net> <57c8f36a-29dc-0365-af4f-96282e253702@connect2id.com> <CA+iA6ugTpEAZe22=uwb31x+F2zVVdM9wUHrar1eiL6UO5e9xuw@mail.gmail.com> <A31F247F-8537-4FC5-AC64-A85927A68D3F@manicode.com>
X-Mailer: Apple Mail (2.3445.101.1)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/CxGvu-HLP6cokim5ZslbKIc88PY>
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
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, 20 Nov 2018 19:39:22 -0000

Hi all, 

please find some thoughts about refresh token protection in the new revision of the Security BCP https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3.12

Feedback welcome!

kind regards,
Torsten. 

> Am 19.11.2018 um 11:33 schrieb Jim Manico <jim@manicode.com>:
> 
> I want to +1 this as well. This really got my attention as an impressive and straightforward defense technique.
> 
> Jim
> 
> 
> On Nov 19, 2018, at 3:48 PM, Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
> 
>> +1 to the suggestions that Vladimir raises; I've seen a fair number of requests  in the field for exactly that
>> 
>> Hans.
>> 
>> On Mon, Nov 19, 2018 at 10:59 AM Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
>> On 17/11/2018 13:26, Torsten Lodderstedt wrote:
>>> To start with, the AS may use refresh token rotation in combination with automatic revocation in case of detected replay attempts. 
>>> 
>>> How does it work? The AS issues a new refresh token with every refresh and invalidate the old one. This restricts the lifetime of a refresh token. If someone (might be the legit client or an attacker) submits one of the older, invalidated refresh token, the AS might interpret this as a signal indicating token leakage and revoke the valid refresh token as well. We used this technique at Deutsche Telekom since our first OAuth 2.0 implementation back in 2012.
>>> 
>> This is a clever solution. Did you experience any false positives, e.g. due to HTTP response timeouts on slow / poor connections?
>> 
>> We were also thinking of additionally binding the refresh token to the end-user session at the AS / OP:
>> 
>> 	• A valid refresh causing the session to be refreshed too
>> 	• AS / OP logout or session expiration invalidating the refresh token
>> 
>> 
>> Vladimir
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> -- 
>> hans.zandbelt@zmartzone.eu
>> ZmartZone IAM - www.zmartzone.eu
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

v2.23.0 | Report a Bug | By Email