Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

Nat Sakimura <> Thu, 21 January 2016 14:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A6B131A8892 for <>; Thu, 21 Jan 2016 06:40:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xht5-kmzPJUa for <>; Thu, 21 Jan 2016 06:40:07 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 656651A888F for <>; Thu, 21 Jan 2016 06:40:07 -0800 (PST)
Received: by with SMTP id 6so32832484qgy.1 for <>; Thu, 21 Jan 2016 06:40:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=TMFKNCT6/8UBM6LOd94rvA9QBqRu+u6wkTmRoPgoXfc=; b=rPY8ZWc02T5lW/WOnYRncKQxaGvcTtDh9a/5N3m8eVZhbb1Xtbf1QbUQrC/FsVhl95 xlYx/e59hOoQwo3f0v/kBS8DMglDmdWO8/op5PbE7UnAorlcbJImhY31AeYKIfHHBaim WI4Nn1fRN/spfZ78mKTdLyYWzuGHAeWcsVTgU0Rbo7RSkCacdof+7AIsp415rSWWai0z /hVRetws0dfM0Yr5QMxVmAUQ5y77xbP/kdXWfSjXIJ8ZeBtUUK7mtNoN/9BTiT7WTGMx JMCdt4Rg8m4NNjU5vGMtYVvy74Hy+tA/tcFLdhm6nfv1KlE7jKRLCtt7z3gLWyBjajy7 JnXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=TMFKNCT6/8UBM6LOd94rvA9QBqRu+u6wkTmRoPgoXfc=; b=JOK7OClKaYIIixZKGkURrt7Hxw6RyhFUBd4svmWCeslJY+HpP5euNSrww0j4fuanZo 0ZNMFHAXAKbm32VaFmBOh1mhbjqBC3kRYADL+CggZyUvG5AvkofciNlmTLl/UC0PnQ9b qi2QJNw/1Xa9DAeJP4rTD0VZzBLHK5FJLgG+1+DfDTrzp/Yz4+lY50fTo7QcqZK+KPhn O8KCH8TvCFzrKXSMxfIBHdH3UhFscZ8TEA/GU0YD/oVb85URqokzCLfauCKANRmM+Bva FuN5EKQT3IPtm+qW9l0hYlWFjzBGuNCTfhehioMUobHoTDJD++0Xw+ZT/v0v19xrtHnd B5Dw==
X-Gm-Message-State: ALoCoQltA4avLegcMQvUz1ZyuZiTIZAefka16uRbT65mglS6VKap0Iu7PLHRZZrS+LUsaNat26qSDAkKL5Jr2uHef/xN3McTxw==
X-Received: by with SMTP id v132mr55923976qhc.0.1453387206555; Thu, 21 Jan 2016 06:40:06 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Nat Sakimura <>
Date: Thu, 21 Jan 2016 14:39:57 +0000
Message-ID: <>
To: Josh Mandel <>, Hannes Tschofenig <>
Content-Type: multipart/alternative; boundary="001a113a99d02aff980529d9140d"
Archived-At: <>
Cc: " WG" <>
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
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:40:13 -0000

Hi Josh,

It is similar but slightly different IMHO.

Section 4.6.4 of the RFC6819 is the access token phishing by a counterfeit
resource server.
The mix-up attack described here is the code phishing by a counterfeit
token endpoint.

In my view, both can be mitigated by the server returning the next step:
i.e., authorization endpoint returning the legitimate token endpoint uri,
and token endpoint returning legitimate resource endpoint uris. This
involves no discovery endpoint, which is good.

Your way also works. It is just the reverse of my proposal. The difference
being that my proposal does not need any coding on the server but just
configuration, and it can return more metadata if needed.



2016年1月21日(木) 23:04 Josh Mandel <>:

> Apologies if this is the wrong forum for my comment (and please direct me
> to the appropriate place in that case), but I have two questions about the
> propose mitigation (and the thinking behind it) that I think the write-up
> could address:
> 1. Could the writeup clarify whether/how the primary "mixup" threat
> differs from what RFC6819 identifies as in section 4.6.4?
> 2. Has the workgroup considered a mitigation that puts more responsibility
> on the authorization server, and less on the client? For example, if would
> be helpful for the writeup to clarify why having the client send an
> "audience field" (in the terminology of RFC6819) to the authorization
> endpoint would not mitigate the threat. (In that scenario, the
> authorization server can recognize that the audience does not correspond to
> a resource server it knows, rather than asking clients to make this check).
> I assume this approach has been considered and rejected as an incomplete
> mitigation, but I don't have visibility into where/how that discussion
> went.
> Thanks,
> Josh
> Hi all,
> this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see
> Please let us know by Feb 9th whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
> Note: This call is related to the announcement made on the list earlier
> this month, see
> More
> time for analysis is provided due to the complexity of the topic.
> Ciao
> Hannes & Derek
> _______________________________________________
> OAuth mailing list
> _______________________________________________
> OAuth mailing list