Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

Justin Richer <jricher@mit.edu> Thu, 21 January 2016 19:18 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C181A8AF4 for <oauth@ietfa.amsl.com>; Thu, 21 Jan 2016 11:18:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 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] autolearn=ham
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 yD4dqKJrB6OZ for <oauth@ietfa.amsl.com>; Thu, 21 Jan 2016 11:18:56 -0800 (PST)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB5831A8AF6 for <oauth@ietf.org>; Thu, 21 Jan 2016 11:18:52 -0800 (PST)
X-AuditID: 12074424-f79216d00000156e-95-56a12f1a840e
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id D1.32.05486.B1F21A65; Thu, 21 Jan 2016 14:18:51 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u0LJIocB016225; Thu, 21 Jan 2016 14:18:50 -0500
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 u0LJImIn027711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Jan 2016 14:18:49 -0500
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/signed; boundary="Apple-Mail=_60419531-FA28-415C-8D31-3FDFE7B70EF4"; protocol="application/pgp-signature"; micalg=pgp-sha256
X-Pgp-Agent: GPGMail 2.5.2
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <9EC932C9-6B31-4A3E-85C8-46DBFF9E3B9B@ve7jtb.com>
Date: Thu, 21 Jan 2016 14:18:47 -0500
Message-Id: <27A7E81B-0E45-4D81-9F02-107E740E82AF@mit.edu>
References: <BY2PR03MB442662C73E3904E73D9B9EFF5C30@BY2PR03MB442.namprd03.prod.outlook.com> <FD34E5B7-2884-4789-9DF3-217F027F6556@ve7jtb.com> <E6B0DFF1-CA4C-4BAA-AC6E-E2A28DEC8CB7@mit.edu> <9EC932C9-6B31-4A3E-85C8-46DBFF9E3B9B@ve7jtb.com>
To: John Bradley <ve7jtb@ve7jtb.com>
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHKsWRmVeSWpSXmKPExsUixG6nriutvzDMYP9Jdou90z6xWJx8+4rN YvXdv2wOzB5Llvxk8mjd8Zfd4/btjSwBzFFcNimpOZllqUX6dglcGfeO/2Ep2H2QseLojtQG xk0rGLsYOTkkBEwkbpw+wgRhi0lcuLeeDcQWEljMJHHuaG4XIxeQvZFR4sH5e4wQzm0miQen prKAVAkLOEhMvXAfrINXQE/i1a3LrCA2s8AURond88W7GDmApkpJzNgvABJmE1CVmL6mBWwZ p4CdxPoFe8FsFqD4xYWn2SBaoyS6d/9khxhpJbFg0SJmiIPeMkps6LMBsUUEVCT27XsE9YCs xO7fj5gmMArOQnLFLCRXQNhJEv/vb2SGsLUlli18DWVrSuzvXs6CKa4h0fltItQceYntb+dA xS0lFs+8AVVvK3GrbwEThG0n8WjaItYFjNyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdM31cjNL 9FJTSjcxgqPSRWUHY/MhpUOMAhyMSjy8HLoLw4RYE8uKK3MPMUpyMCmJ8n7VAQrxJeWnVGYk FmfEF5XmpBYfYlQB2vVow+oLjFIsefl5qUoivClKQHW8KYmVValF+TBl0hwsSuK8uzrmhgkJ pCeWpGanphakFsFkZTg4lCR4i/SAGgWLUtNTK9Iyc0oQ0kwcnIcYJTh4gIavArmLt7ggMbc4 Mx0if4pRUUqcdy5IQgAkkVGaB9cLSqYJbw+bvmIUB3pLmPciSBUPMBHDdb8CGswENHiv2XyQ wSWJCCmpBka9haZHih/pzu2LeePIc93QiPHlM68Ep3PPL6RtVSkrVPdiPfHzoeOxlc0lvCee FUWzG/xjMd7wwlJlgpswc59MYbrjrb3/azcKT+9x1X6/x1V6mhGrVMvDjlkejy26V15dEjZx drlpRNqun01X7sTVa7Yz9lg8kXN5q/Fw3yy7tw29ooJ5RkosxRmJhlrMRcWJAL6jK8SBAwAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/LAej3dusCNcUrbGezsZPJInbkJY>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 21 Jan 2016 19:18:59 -0000

Just because there’s a potential workaround doesn’t mean this is a good idea, especially when you can easily avoid the need for workarounds in the first place. :)

 — Justin

> On Jan 21, 2016, at 2:15 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
> 
> The server could hash the state using the same algorithm the client uses if the client passed that as well.
> 
> I see lots of things being fragile about that.
> 
> The draft allows the server to use whatever hash it wants to internally to compare them.  Given that we are detecting tamping and don’t need to worry about collisions as the state should have it’s own integrity protection you could probably get away with MD5 on the server.  Though I don’t think saying that in a spec would be a good idea:)
> 
> I am being sensitive, because I am changing a decision that was agreed to by the group in Germany.   I want people to know it was changed, so they can provide feedback if they feel strongly.
> 
> John B.
> 
>> On Jan 21, 2016, at 3:58 PM, Justin Richer <jricher@MIT.EDU <mailto:jricher@mit.edu>> wrote:
>> 
>> Thank you for removing state hashing and please don’t add it back. It’s security theater, and that’s giving it the benefit of the doubt. Remember, this is being sent in a  request where other parameters (code, client_id, client_secret, redirect_uri) are all sent plain over TLS as well. Either come up with a general mechanism to hash everything or don’t hash anything. The latter is more likely to win, and it’s the only thing that makes sense currently.
>> 
>> Also, keep in mind that if the client hashes the state on the second request, then the server can’t store the state parameter using its own hash methods (for data-at-rest protection) and still be able to do the comparison. Having the client send it over plain is really better all around in terms of simplicity and adoptability.
>> 
>> Now if we really wanted to have message-level protection of HTTP requests, I can think of a good way to do that…
>> 
>>  — Justin
>> 
>> 
>>> On Jan 21, 2016, at 9:41 AM, John Bradley <ve7jtb@ve7jtb.com <mailto:ve7jtb@ve7jtb.com>> wrote:
>>> 
>>> We merged the state verification in with this rather than forcing people to also look at the JWT encoded State draft.  https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state <https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state>.
>>> 
>>> While JWT encoded state is how I would do state in a client and at-least one client I know of uses it, it is not the only way to manage state, and I am hesitant that developers might be scared away by thinking they need to encode state as a JWT.
>>> 
>>> I decided that cross referencing them is better.   This made sending much simpler to describe.
>>> 
>>> I also removed the hashing from state.   That cut the text by about 2/3 by not having to describe character set normalization so that both the client and the AS could calculate the same hash.
>>> That also achieved the goal of not requiring a simple OAuth client doing the code flow to add a crypto library to support SHA256.
>>> 
>>> Once we make a algorithm mandatory, we need to defend why we don’t have crypto agility eg support for SHA3 etc.  We would be forced by the IESG to add another parameter to the request to specify the hash alg if we went that direction.
>>> 
>>> Given that we assume state to be public info in the request that an attacker can see, hashing state provides not much value for a lot of complexity that people may get wrong or not implement.
>>> 
>>> I appreciate why from a theory point of view hashing it would have been better.
>>> 
>>> If people really want it I can add it back.
>>> 
>>> John B.
>>> 
>>>> On Jan 21, 2016, at 3:28 AM, Mike Jones <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>> wrote:
>>>> 
>>>> John Bradley and I collaborated to create the second OAuth 2.0 Mix-Up Mitigation draft.  Changes were:
>>>> ·       Simplified by no longer specifying the signed JWT method for returning the mitigation information.
>>>> ·       Simplified by no longer depending upon publication of a discovery metadata document.
>>>> ·       Added the “state” token request parameter.
>>>> ·       Added examples.
>>>> ·       Added John Bradley as an editor.
>>>> 
>>>> The specification is available at:
>>>> ·       http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 <http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01>
>>>> 
>>>> An HTML-formatted version is also available at:
>>>> ·       http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html <http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html>
>>>> 
>>>>                                                           -- Mike
>>>> 
>>>> P.S.  This note was also posted at http://self-issued.info/?p=1526 <http://self-issued.info/?p=1526> and as @selfissued <https://twitter.com/selfissued>.
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>