Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft
Hans Zandbelt <hzandbelt@pingidentity.com> Thu, 21 January 2016 19:25 UTC
Return-Path: <hzandbelt@pingidentity.com>
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 A8D7B1A8AFB for <oauth@ietfa.amsl.com>; Thu, 21 Jan 2016 11:25:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 94tKMzLGAJiv for <oauth@ietfa.amsl.com>; Thu, 21 Jan 2016 11:24:59 -0800 (PST)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C7441A8AF9 for <oauth@ietf.org>; Thu, 21 Jan 2016 11:24:59 -0800 (PST)
Received: by mail-wm0-x22e.google.com with SMTP id l65so233327253wmf.1 for <oauth@ietf.org>; Thu, 21 Jan 2016 11:24:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=4ntgol5iiSJ5eeyUGZ8jKmk+flBNc94C/IyP4AnuCfU=; b=MsnyOOFUhj250YlxTqpHlShCCKagP05XPzO4wF+JrViUaWnib8MGRAUxR0UYIhhS5x 6/lOEHepbh22eOrfgXdGmr2ayCH/0ApBXqrFNHqonJ9iaEbI/1fm0bEMMC4ZrrGnkbX5 /q9MPrx+5Gj71NqahyJrpwsz7T/1Blt/+d4rs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=4ntgol5iiSJ5eeyUGZ8jKmk+flBNc94C/IyP4AnuCfU=; b=hWRfjyd3w8TuUP5/OSWeAKiV86Humn1EjneIrdW1qdFl1utE4CFFzQFAppqWRnnm2V I4Pubw2AGQ68tP7F8LiLeT/nKWW+UHwUjaCvhe3jKSK4RT1tVVgy2wTlBtMg5pQFSK9w AD3aULTI/xQA0vVh0dSWftvRvRcBFCga0UESxskyU9zSQdON2qzyE1o2hJ/lfumxHb43 iboMw5rUXqegfWNIkbR+eMcsNwBaD6T9ClX6VA3DWqVYSRrSATyM9KJIx7eZ2pRmQOOo dDy/M5nPDrESAjv5M0G8MsleT4p964x3pV3C1bHyQtMCvBF7TGNyr+6X15AMeFbNNaiX gREA==
X-Gm-Message-State: AG10YOTGZ77JTmPUnZhNMKvkSxToxEX8VoTT0EklgWXckm5ijJDCpCI9HGUWFZqi5IiOCMJ9
X-Received: by 10.28.225.8 with SMTP id y8mr12524486wmg.98.1453404297879; Thu, 21 Jan 2016 11:24:57 -0800 (PST)
Received: from [192.168.10.222] (5ED52E8A.cm-7-6a.dynamic.ziggo.nl. [94.213.46.138]) by smtp.gmail.com with ESMTPSA id w73sm4192461wmw.21.2016.01.21.11.24.56 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Jan 2016 11:24:57 -0800 (PST)
To: Justin Richer <jricher@mit.edu>, John Bradley <ve7jtb@ve7jtb.com>
References: <BY2PR03MB442662C73E3904E73D9B9EFF5C30@BY2PR03MB442.namprd03.prod.outlook.com> <FD34E5B7-2884-4789-9DF3-217F027F6556@ve7jtb.com> <E6B0DFF1-CA4C-4BAA-AC6E-E2A28DEC8CB7@mit.edu>
From: Hans Zandbelt <hzandbelt@pingidentity.com>
Message-ID: <56A13088.2000508@pingidentity.com>
Date: Thu, 21 Jan 2016 20:24:56 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <E6B0DFF1-CA4C-4BAA-AC6E-E2A28DEC8CB7@mit.edu>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/1zP3W2Wkhv9_ZKzo24lYl6jKQXQ>
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:25:01 -0000
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)