Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft
Justin Richer <jricher@mit.edu> Thu, 21 January 2016 19:42 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 7023B1A8FD2 for <oauth@ietfa.amsl.com>; Thu, 21 Jan 2016 11:42:10 -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 JVfFfHmIZMGv for <oauth@ietfa.amsl.com>; Thu, 21 Jan 2016 11:42:07 -0800 (PST)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 251ED1A8F51 for <oauth@ietf.org>; Thu, 21 Jan 2016 11:42:05 -0800 (PST)
X-AuditID: 1209190c-f79c96d00000038e-58-56a1348c6b43
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 2A.D1.00910.C8431A65; Thu, 21 Jan 2016 14:42:04 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u0LJg319022457; Thu, 21 Jan 2016 14:42:03 -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 u0LJg1OJ003973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Jan 2016 14:42:02 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_3A9D313F-46BC-4946-AC8B-2CA2D3645500"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <56A13088.2000508@pingidentity.com>
Date: Thu, 21 Jan 2016 14:42:01 -0500
Message-Id: <B51182F4-D284-4C8A-BE4D-38BC5359DEDA@mit.edu>
References: <BY2PR03MB442662C73E3904E73D9B9EFF5C30@BY2PR03MB442.namprd03.prod.outlook.com> <FD34E5B7-2884-4789-9DF3-217F027F6556@ve7jtb.com> <E6B0DFF1-CA4C-4BAA-AC6E-E2A28DEC8CB7@mit.edu> <56A13088.2000508@pingidentity.com>
To: Hans Zandbelt <hzandbelt@pingidentity.com>
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNKsWRmVeSWpSXmKPExsUixCmqrdtjsjDMYOtfMYutf/cyW5x8+4rN YvXdv2wOzB5Llvxk8rh79CKLx+3bG1kCmKO4bFJSczLLUov07RK4Mj5vKi7YXVDxr2EaUwPj pIQuRk4OCQETiRnPnjJC2GISF+6tZ+ti5OIQEljMJNH/4DkzhLORUWLOhwaozG0miXt/X7OB tDALJEi0fLwDZvMK6Em8unWZFcQWFnCQmHrhPlicTUBVYvqaFiYQm1PAQGLOumPMIDYLUHzO lS0sEHM8JfY8u8AIMcdK4sGjSywQy+4zSlx41QBWJAK0YO+lhUwQt8pK7P79iGkCo8AsJHfM QnIHRFxbYtnC18wQtoHE085XWMT1Jd68m8O0gJFtFaNsSm6Vbm5iZk5xarJucXJiXl5qka6h Xm5miV5qSukmRnAcSPLsYHxzUOkQowAHoxIPL4fuwjAh1sSy4srcQ4ySHExKorxfdYBCfEn5 KZUZicUZ8UWlOanFhxglOJiVRHhTlIByvCmJlVWpRfkwKWkOFiVx3l0dc8OEBNITS1KzU1ML UotgsjIcHEoSvI+MgRoFi1LTUyvSMnNKENJMHJwgw3mAhp8CqeEtLkjMLc5Mh8ifYlSUEud1 AkkIgCQySvPgekFpKuHtYdNXjOJArwjzloJU8QBTHFz3K6DBTECD95rNBxlckoiQkmpgLGIv sd2VJbYs8q00p6m26ZLvK1///HhDeVK20N0IuSmOfxtkqjTrmhaXO794PnvaYuOTlzz8ZVN2 X+Nee2Ozq75Z65laifhGBpbFWdteGy3wjZUJK/ikVzVpd9pjtbfHjYwYhO7rxiS0in0xcbcQ 4AvQ3MiY+0rsn0vOadZT7UqT0mqC36cqsRRnJBpqMRcVJwIAEeivZi4DAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/XlsbKgBQAE-7PMKGVhnhRLxpff0>
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:42:10 -0000
Hans, Thanks; while I see the argument, my counter argument was to ask for a situation where you’d want to protect the state value but not code, client_secret, redirect_uri, and everything else in the request. If you actually want to protect all of that, it’s better to have a message-level protection mechanism instead of a piecemeal solution. — Justin > On Jan 21, 2016, at 2:24 PM, Hans Zandbelt <hzandbelt@pingidentity.com> wrote: > > Note that the argument was not about message-level protection: it was about not disclosing the state value verbatim over the token endpoint. > > I don't feel strongly about it either; it was just what was agreed at first. Since no-one actually came up with even a hypothetical attack I guess it makes sense to revert that decision. > > Hans. > > On 1/21/16 7:58 PM, Justin Richer 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. >>> >>> 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 >>>> An HTML-formatted version is also available at: >>>> ·http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html >>>> -- Mike >>>> P.S. This note was also posted >>>> athttp://self-issued.info/?p=1526andas@selfissued >>>> <https://twitter.com/selfissued>. >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > -- > Hans Zandbelt | Sr. Technical Architect > hzandbelt@pingidentity.com | Ping Identity
- [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Dra… Mike Jones
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… John Bradley
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… Justin Richer
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… John Bradley
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… Justin Richer
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… Hans Zandbelt
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… Justin Richer
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… David Waite
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… John Bradley
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… David Waite
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… John Bradley
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… William Denniss
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… Thomas Broyer
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… John Bradley
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… George Fletcher
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… David Waite
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… John Bradley
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… Paul Madsen
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… George Fletcher
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… Roland Hedberg
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… George Fletcher
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… Torsten Lodderstedt
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… Phil Hunt (IDM)