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

John Bradley <> Thu, 21 January 2016 14:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 059661A88AD for <>; Thu, 21 Jan 2016 06:41:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vHFbO3q4W_sR for <>; Thu, 21 Jan 2016 06:41:34 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 498871A88A3 for <>; Thu, 21 Jan 2016 06:41:34 -0800 (PST)
Received: by with SMTP id o6so16509977qkc.2 for <>; Thu, 21 Jan 2016 06:41:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=QCnfN5+JAowzmtPt+4I6IrxdCc02rZTyraX+BkOq0Eo=; b=jw4OkfCwwYc6rdDNABS8abmLoqiNKNMHIWqUY04KrZ5tkfck6JwIeZm7z5r/PH05DY oxISz/wzVDVLMoAeXZROStrqjvjrcp/dQ81gYTpewMepR+3ySI1LeobEhaRskkG8fJ5u 6tO6+QWcwjsXizUmxEfIWG+C7ObInxBedmaHJ9HfHlevkXs/Jch9rOvj85yiduS8in6x EwWsXCL2WPQwiq5peZuC2K694hHyENvFgOreGSK4CpeoWS4ayPee9RyjnkaFMOWG+0dw gGxAZHCAsSiOBUCNwVvsq1stpQysncac/q5xGEaxwQeijImwVB/YyOQ1c6K/iHPVmnGJ NsLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=QCnfN5+JAowzmtPt+4I6IrxdCc02rZTyraX+BkOq0Eo=; b=DAdIjQIX340ZWujef3AwIrQYbJ1x1GtpXraG7Camw72VQzw4tgO2Ud8L9vZ0xxCxcL k6u6JNaDH0TtUrAuCoJ5t8g1xdYQF8HkHMGN9JpZab+OnqiHvEC61jZZHxPRFuase+gN jwmmXekqIFhZe6ZjjcnwwNYbiI9b5nCe0kBt90YpzjmVQldPtVhZNqesqtEvAW/V/tVc XZ9pwvtT3VotADWEkUBO5fKMALn0oLQtACoEylI0an/MmXtn0guSS9KK029Y/qcRnIzj cf1a6Haqv/yos2zDlEv786/DC4x0wAXs9SUNBYrBsp5xDLm2XOxroAQGmbWcbcL+34nR lXhg==
X-Received: by with SMTP id c67mr51799775qkb.37.1453387293403; Thu, 21 Jan 2016 06:41:33 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id e34sm650345qga.4.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jan 2016 06:41:32 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_9510D4B7-5ACB-445D-A508-54762E9A76D4"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley <>
In-Reply-To: <>
Date: Thu, 21 Jan 2016 11:41:31 -0300
Message-Id: <>
References: <>
To: Michael Jones <>
X-Mailer: Apple Mail (2.3112)
Archived-At: <>
Cc: "" <>
Subject: Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Jan 2016 14:41:37 -0000

We merged the state verification in with this rather than forcing people to also look at the JWT encoded State draft.  

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 <> 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:
> · <>
> An HTML-formatted version is also available at:
> · <>
>                                                           -- Mike
> P.S.  This note was also posted at <> and as @selfissued <>.
> _______________________________________________
> OAuth mailing list
> <>
> <>