Re: [OAUTH-WG] RFC 7009

Justin Richer <jricher@mit.edu> Tue, 06 June 2017 22:18 UTC

Return-Path: <jricher@mit.edu>
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 3209A129410 for <oauth@ietfa.amsl.com>; Tue, 6 Jun 2017 15:18:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.685
X-Spam-Level:
X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506, T_KAM_HTML_FONT_INVALID=0.01] 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 qy1b1lNUidRM for <oauth@ietfa.amsl.com>; Tue, 6 Jun 2017 15:18:30 -0700 (PDT)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 74E33128B93 for <oauth@ietf.org>; Tue, 6 Jun 2017 15:18:30 -0700 (PDT)
X-AuditID: 1209190f-0ddff70000000a50-29-59372a347bab
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 38.FB.02640.43A27395; Tue, 6 Jun 2017 18:18:29 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v56MIRig012569; Tue, 6 Jun 2017 18:18:27 -0400
Received: from [192.168.128.48] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v56MIPpS015302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Jun 2017 18:18:26 -0400
From: Justin Richer <jricher@mit.edu>
Message-Id: <D9196138-6F17-4382-A14A-FECAD0A70357@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B947A3B8-7DA5-4908-9788-94BBD8A7BA24"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 6 Jun 2017 18:18:24 -0400
In-Reply-To: <DM5PR03MB292236BB93A86422285D63DA85CB0@DM5PR03MB2922.namprd03.prod.outlook.com>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
To: Brig Lamoreaux <Brig.Lamoreaux@microsoft.com>
References: <CY4PR03MB2920241827103D122E9EC82085FF0@CY4PR03MB2920.namprd03.prod.outlook.com> <FAF2C6DD-0A7A-4BE1-BDD3-E54B822CCD4D@mit.edu> <DM5PR03MB292263A0429C2BEE01E95BB085CB0@DM5PR03MB2922.namprd03.prod.outlook.com> <cc72fa5b-cd75-e6d6-7b80-af5e009c5cb2@mit.edu> <DM5PR03MB292236BB93A86422285D63DA85CB0@DM5PR03MB2922.namprd03.prod.outlook.com>
X-Mailer: Apple Mail (2.3273)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IRYrdT0TXVMo80WHZP0OLMs9/MFiffvmJz YPJYsuQnk0frjr/sAUxRXDYpqTmZZalF+nYJXBmfWxezFTSvZKyYfXgDSwPjtCmMXYwcHBIC JhI7Ztt1MXJxCAksZpKYtvwUG4SzgVHi0rJtzF2MnEDOLSaJuY9VQGw2AVWJ6WtamEBsXgEr iVc3lzKC2MwCSRLfPk1mBRnKK6Av0fscLCwsoCBxeMlRsDEsAioSR/7/ZAOxOQViJabPe8YE Us4soC7RftIFJCwiYCjROqONFWLrEyaJtmXuILaEgKzErdmXmCcw8s9CsmwWwjKIsLbEsoWv mSFsTYn93ctZMMU1JDq/TWRdwMi2ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdELzezRC81pXQT IyioOSX5dzDOafA+xCjAwajEw5uxxyxSiDWxrLgy9xCjJAeTkihv5CWgEF9SfkplRmJxRnxR aU5q8SFGCQ5mJRHeOg3zSCHelMTKqtSifJiUNAeLkjivuEZjhJBAemJJanZqakFqEUxWhoND SYI3UhOoUbAoNT21Ii0zpwQhzcTBCTKcB2j4OTWQ4cUFibnFmekQ+VOMilLivAIgWwVAEhml eXC9oKST8Paw6StGcaBXhHlXgVTxABMWXPcroMFMQIP5LpmADC5JREhJNTAaaa8wmr6zVO3k ZPcDExRmTEr6+KLez3vuszCOKzYWX2NXvA5Xvjuvkf3Rnp5fBu8qpjyaWpYnOy12ocOV7rsC i2+llWxPmlHomLFb4Vrdyjsd19bndGTb7D26MflMxJf+zgB/1Zrtf6fN4Zn74KjAw8xNSko3 Ui+ztkycsbBgh0kio+k7Wb/DSizFGYmGWsxFxYkAP++0sxUDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/bfQJvpewcuGQ5H6OGZfQb8ivWL0>
Subject: Re: [OAUTH-WG] RFC 7009
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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, 06 Jun 2017 22:18:33 -0000

That really depends on the nature of your tokens and how you manage their internal validity. It’s really as soon as possible, isn’t it? If you can invalidate it immediately, do that. In our implementation, we delete it from the data store as soon as the revocation request comes in, which invalidates it. Downstream RS’s might have cached introspection (RFC7662) results so they’ll find out once their caches expire. If you’ve got some other synchronization method that takes some time to propagate, then that’s going to be the answer. All of this is dependent on your implementation and not on the revocation protocol, but in all cases I see no reason to *wait* any amount of time to revoke a token that’s been requested for revocation by a client, for any reason. The client is effectively saying “if you see this token again it isn’t from me”, which should be a good enough indication to throw it out as soon as possible.

This all falls apart if you’re using self-contained tokens — there’s not a good way to invalidate a self-contained token without using some kind of lookup service. RFC7662 defines such a service for OAuth, but then your tokens aren’t really fully self-contained anymore and you’re simply stuck waiting for the compromised token to expire.

 — Justin

> On Jun 6, 2017, at 6:11 PM, Brig Lamoreaux <Brig.Lamoreaux@microsoft.com> wrote:
> 
> This is where we have the question around timeouts. If the client thinks its token is compromised, how long should 7009 take to invalidate.
>  
>  
>   <>
> From: Justin Richer [mailto:jricher@mit.edu] 
> Sent: Tuesday, June 6, 2017 2:46 PM
> To: Brig Lamoreaux <Brig.Lamoreaux@microsoft.com>
> Cc: <oauth@ietf.org> <oauth@ietf.org>
> Subject: Re: [OAUTH-WG] RFC 7009
>  
> 7009 doesn't, really. If the client thinks its token is compromised, it can revoke it using 7009. If the server decides the token is compromised, it invalidates it on its own, not involving 7009. The client finds out the token isn't good anymore the next time it tries to use the token -- OAuth clients always need to be prepared for their token not working at some point. Good news is that the remedy for having a token that doesn't work is to just do OAuth again.
> 
>  -- Justin
> 
>  
> On 6/6/2017 5:43 PM, Brig Lamoreaux wrote:
> Thanks for the reply. How do the RFC address a token that has been compromised?
>  
> From: Justin Richer [mailto:jricher@mit.edu <mailto:jricher@mit.edu>] 
> Sent: Tuesday, June 6, 2017 9:12 AM
> To: Brig Lamoreaux <Brig.Lamoreaux@microsoft.com> <mailto:Brig.Lamoreaux@microsoft.com>
> Cc: <oauth@ietf.org> <mailto:oauth@ietf.org> <oauth@ietf.org> <mailto:oauth@ietf.org>
> Subject: Re: [OAUTH-WG] RFC 7009
>  
> OAuth doesn’t specify and specific timeout period, it’s up to the AS that issues the token to determine how long the token is good for. RFC7009 isn’t about timeout periods, it’s about the client proactively telling the AS that it doesn’t need a token anymore and the AS should throw it out, likely prior to any timeouts.
>  
>  — Justin
>  
> On May 25, 2017, at 12:23 PM, Brig Lamoreaux <Brig.Lamoreaux@microsoft.com <mailto:Brig.Lamoreaux@microsoft.com>> wrote:
>  
> Hi,
> 
> What is the specified timeout period to invalidate the token?
>  
> Brig Lamoreaux
> Data Solution Architect
> brig.lamoreaux@microsoft.com <mailto:brig.lamoreaux@microsoft.com>
> 480-828-8707
> US Desert/Mountain Tempe
>  
>  
> <image001.jpg>
>  
>  
>  
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CBrig.Lamoreaux%40microsoft.com%7C538020425e8a411a106408d4acf6ca32%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636323623328232170&sdata=UHQOwegm2k8MbWPCYHR3a4ted39xMFlfjil4FdJqyA8%3D&reserved=0>
>  
>