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

Torsten Lodderstedt <> Tue, 26 January 2016 20:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DEF621A00CA for <>; Tue, 26 Jan 2016 12:10:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.251
X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fxgfmWl-CSFE for <>; Tue, 26 Jan 2016 12:10:22 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 10F461B2C5B for <>; Tue, 26 Jan 2016 12:10:22 -0800 (PST)
Received: from [] (helo=[]) by with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <>) id 1aO9wP-0003Jm-Cq; Tue, 26 Jan 2016 21:10:17 +0100
To: Mike Jones <>, "" <>
References: <>
From: Torsten Lodderstedt <>
Message-ID: <>
Date: Tue, 26 Jan 2016 21:10:07 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------070202000207060400050100"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <>
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: Tue, 26 Jan 2016 20:10:28 -0000

Hi Mike,

I really like the new revision since it is much simpler :-)

My comments:

I'm fine with describing all mitigations we talked about in Darmstadt in 
one/this spec. But the state check at the tokens endpoint is supposed to 
be a mitigation against code injection/cut and paste attack, which is 
not directly related to IDP/AS mix up. So I would suggest to change the 
name of the spec, probably "OAuth security extensions"?

I think the code injection/cut and paste attack should be described more 
extensively in the introduction. It's important for the reader to 
understand, why this mitigation is defined at all. Moreover, I think the 
description of the mitigation is still incomplete/spread over the 
document. In order to detect code injection, the RP not only needs to 
send the state to the tokens endpoint, it also needs to (directly or 
indirectly) _bind_ the state to the particular user agent (session). 
Otherwise, the attacker can inject the state along with the solen code 
easily. I would suggest to merge

          "To prevent replay of the state in another browser instance by 
an attacker, the state value MUST be tied to the browser instance in a 
way that cannot be forged by an attacker. Section 4 of 
          provides several examples of how a client can accomplish this."

into section 5.

I thought we had discussed to also give implementors a guideline on 
using state to prevent CSRF as well? How will we take care of that topic?

kinds regards,

Am 21.01.2016 um 07:28 schrieb Mike Jones:
> 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