IETF Logo Mail Archive

Re: [OAUTH-WG] RFC 7009

Brig Lamoreaux <Brig.Lamoreaux@microsoft.com> Tue, 06 June 2017 22:11 UTC

Return-Path: <Brig.Lamoreaux@microsoft.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 A68C0126E01 for <oauth@ietfa.amsl.com>; Tue, 6 Jun 2017 15:11:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.484
X-Spam-Level: *
X-Spam-Status: No, score=1.484 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 1uLjoFRbFlse for <oauth@ietfa.amsl.com>; Tue, 6 Jun 2017 15:11:31 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0124.outbound.protection.outlook.com [104.47.40.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F3CE126D45 for <oauth@ietf.org>; Tue, 6 Jun 2017 15:11:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1lDM/+mkfjUvULUKEjvTK3kPIpcxHNn4GakFVPfC4WA=; b=Uz2qPM95ezRXnARnuIadldTWgI7l3yLsAXqYXz5V82hoG2tOFFiqXcVX2L/3AJ3JHNItYs1trQ5pDW6vPh5pjb2SOAgBZfShjmkViRT3YFjd/HwekXf7q32vx1BEe8catihddqYTrLxLdbxVNJumsK5wgelWVHowXynEcoFN5Wg=
Received: from DM5PR03MB2922.namprd03.prod.outlook.com (10.175.106.20) by DM5PR03MB2921.namprd03.prod.outlook.com (10.175.106.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.12; Tue, 6 Jun 2017 22:11:28 +0000
Received: from DM5PR03MB2922.namprd03.prod.outlook.com ([10.175.106.20]) by DM5PR03MB2922.namprd03.prod.outlook.com ([10.175.106.20]) with mapi id 15.01.1157.012; Tue, 6 Jun 2017 22:11:28 +0000
From: Brig Lamoreaux <Brig.Lamoreaux@microsoft.com>
To: Justin Richer <jricher@mit.edu>
CC: "<oauth@ietf.org>" <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] RFC 7009
Thread-Index: AdLVcSY9VMwm5v7UR7a29hVsc2krjwJbn5+AAAt1W1AAADCqgAAAxENA
Date: Tue, 06 Jun 2017 22:11:24 +0000
Deferred-Delivery: Tue, 6 Jun 2017 22:10:26 +0000
Message-ID: <DM5PR03MB292236BB93A86422285D63DA85CB0@DM5PR03MB2922.namprd03.prod.outlook.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>
In-Reply-To: <cc72fa5b-cd75-e6d6-7b80-af5e009c5cb2@mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [72.223.34.197]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR03MB2921; 7:F+eInEdGe9F79bNG9G0B0bXPMhR8Ptjngu06z8BKC+zuIldjF7LGR8lT7n4HEGPakMZeNZ+xvKM0lQYXFSRIJs/n2Pl5lBjClQ9PLnDWOrSDX3rCF1kx4t3ZK2YnwmE08KQT79IEW/PU6WBtAdKkpnhfwwV6AxHDBaNBkDUZhwQA9XwtZzynxwl+n871Z17fpnBgEARwgSVwPY5GYoSO4Ay1RB/PHFi1TU7lYLH7p7NWSAnN/5lXFM0MrXyX203CWG/La5qtMaVxClDQfARRF0BoAZQDujfDd7P9S3LaeI6ZYMavyXb640ee4ZC0oytAFO13gDX1h7ip903jOMr6uBSUBd9NhimO6ygmOhv88k4=
x-ms-traffictypediagnostic: DM5PR03MB2921:
x-ms-office365-filtering-correlation-id: 155f2b3c-3f2f-4516-2355-08d4ad28fb0f
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR03MB2921;
x-microsoft-antispam-prvs: <DM5PR03MB2921C218740FFA716650F25685CB0@DM5PR03MB2921.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(189930954265078)(219752817060721)(176510541525296)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR03MB2921; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR03MB2921;
x-forefront-prvs: 033054F29A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39840400002)(39410400002)(39860400002)(39850400002)(39400400002)(24454002)(377454003)(53546009)(6916009)(6436002)(189998001)(606005)(7696004)(77096006)(6506006)(2950100002)(10090500001)(5005710100001)(110136004)(38730400002)(99286003)(72206003)(53936002)(966005)(6246003)(55016002)(2171002)(9686003)(10290500003)(54896002)(14454004)(236005)(25786009)(102836003)(6116002)(790700001)(4326008)(86362001)(3846002)(478600001)(6306002)(229853002)(81166006)(8676002)(8936002)(7736002)(74316002)(93886004)(50986999)(7906003)(5660300001)(6666003)(76176999)(54356999)(3280700002)(33656002)(2906002)(66066001)(122556002)(3660700001)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR03MB2921; H:DM5PR03MB2922.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM5PR03MB292236BB93A86422285D63DA85CB0DM5PR03MB2922namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2017 22:11:28.6421 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR03MB2921
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/5M7riOIuGXr2paEDyGKU1fo08qo>
X-Mailman-Approved-At: Wed, 07 Jun 2017 06:15:09 -0700
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:11:34 -0000

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]
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>

v2.23.0 | Report a Bug | By Email