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

John Bradley <> Fri, 22 January 2016 12:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 540F61A1B9E for <>; Fri, 22 Jan 2016 04:45:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0c-F9GCYPJSm for <>; Fri, 22 Jan 2016 04:45:21 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 81A501A1BB8 for <>; Fri, 22 Jan 2016 04:45:21 -0800 (PST)
Received: by with SMTP id a85so84536877ykb.1 for <>; Fri, 22 Jan 2016 04:45:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=etryfFTgDdjRrd6zc1pr6pGIpWmCwlLoVnkxWNO9u6U=; b=LbuhSNs5h2PlXlBO+SCphv86SoDO/JGV+3DlnvQcC5/2f+I3aX0VYIsd++DzqqKPkK Nwe7qPsn9yJgmQ/BBipRgLTly4Y8Czc+9EQCYpO2p5k192hg7oLrLAwaKNKbY+t7+bp9 u4G8ys5UhFYI4a+1BEfnel6rH4N0XiINkTDZ8VdbitlSjaIJ3H/KKJWqmJRAqfCvVZKF OxZelEDfuaulVPwCFciXcUc1+vyAESvpnEV2RYgMsoBK2eINZ7yTwpwsWTlMnbv7zkn0 yvhrhMvA1Oz4dph+rJooNQJ1TrERywHKXxLEpO/l6LwyorptlDtTuA4ItFDzWc/ejF15 gLWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=etryfFTgDdjRrd6zc1pr6pGIpWmCwlLoVnkxWNO9u6U=; b=AGFLfu8wzgIaRLTlmpDuKVy/QdEpSrGMufu+GqaaUSUfjxToPWJ4lOZClH9TYTLZdZ +sS2lef5iz/hogVi9jH/R2RigSjleVN/qHV4+61o3cNdeQC+LGSACeblB9+Arlhs1yuF rvBE2JT6ZKT5Wm9K7jZkxdCYKzZtimX7y9zjQE9mOGGWBJtgEsc7ODbDnUVeHq1YuKcF 3qLnRQ5+l8eKQ/2kNmTMREg5ZccFG0RP7n/jyIFlRgw+qXq23qGSIAZakV/fH5ZNYkwJ Ev5beEMrsTIGahnSuoxUv2hXtZl6vOfDTpb/Xl+6b7nFYTvUFYfLrdx+0llMMZRf82to aDmA==
X-Gm-Message-State: AG10YOQbxRuQjVEwVdNULvOH1r0gJtJJy935QD7ZiqED10AY7zvQTv7W4oXJz/NCoC7vPVqn5WFoW0+v0fo2RA==
MIME-Version: 1.0
X-Received: by with SMTP id e73mr1277722ybb.26.1453466720623; Fri, 22 Jan 2016 04:45:20 -0800 (PST)
Received: by with HTTP; Fri, 22 Jan 2016 04:45:20 -0800 (PST)
Received: by with HTTP; Fri, 22 Jan 2016 04:45:20 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Fri, 22 Jan 2016 09:45:20 -0300
Message-ID: <>
From: John Bradley <>
To: David Waite <>
Content-Type: multipart/alternative; boundary="001a113e9d3493906b0529eb9773"
Archived-At: <>
Cc: IETF oauth WG <>
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: Fri, 22 Jan 2016 12:45:23 -0000

Perhaps Frankenstein response is a better name than cut and paste attack.

John B.
On Jan 22, 2016 1:22 AM, "David Waite" <> wrote:

> On Jan 21, 2016, at 2:50 PM, John Bradley <> wrote:
> In that case you probably would put a hash of the state in the code to
> manage size.  The alg would be up to the AS, as long as it used the same
> hash both places it would work.
> Yes, true.
> Sending the state to the token endpoint is like having nonce and c_hash in
> the id_token, it binds the issued code to the browser instance.
> I think I understand what you are saying. Someone won’t be able to
> frankenstein up a state and a token from two different responses from an
> AS, and have a client successfully fetch an access token based on the
> amalgamation.
> This protects against codes that leak via redirect uri pattern matching.
> failures etc.  It prevents an attacker from being able to replay a code
> from a different browser.
> Yes, if a party intercepts the redirect_url, or the AS fails to enforce
> one time use (which even for a compliant implementation could just mean the
> attacker was faster than the state propagated within the AS)
> Makes sense. Thanks John.
> -DW
> If the client implements the other mitigations on the authorization
> endpoint, then it wouldn't be leaking the code via the token endpoint.
> The two mitigations are for different attacks, however some of the attacks
> combined both vulnerabilities.
> Sending the iss and client_id is enough to stop the confused client
> attacks, but sending state on its own would not have stopped all of them.
> We discussed having them in separate drafts, and may still do that.
> However for discussion having them in one document is I think better in the
> short run.
> John B.
> On Jan 21, 2016, at 4:48 PM, David Waite <>
> wrote:
> Question:
> I understand how “iss" helps mitigate this attack (client knows response
> was from the appropriate issuer and not an attack where the request was
> answered by another issuer).
> However, how does passing “state” on the authorization_code grant token
> request help once you have the above in place? Is this against some
> alternate flow of this attack I don’t see, or is it meant to mitigate some
> entirely separate attack?
> If one is attempting to work statelessly (e.g. your “state” parameter is
> actual state and not just a randomly generated value), a client would have
> always needed some way to differentiate which issuer the authorization_code
> grant token request would be sent to.
> However, if an AS was treating “code” as a token (for instance, encoding:
> client, user, consent time and approved scopes), the AS now has to include
> the client’s state as well. This would effectively double (likely more with
> encoding) the state sent in the authorization response back to the client
> redirect URL, adding more pressure against maximum URL sizes.
> -DW