Re: [OAUTH-WG] Call for Adoption

Antonio Sanso <> Wed, 27 January 2016 17:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 295E31A9062 for <>; Wed, 27 Jan 2016 09:10:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YAXK8jbLBrU6 for <>; Wed, 27 Jan 2016 09:10:06 -0800 (PST)
Received: from ( [IPv6:2a01:111:f400:fc10::1:687]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C773A1ACDCC for <>; Wed, 27 Jan 2016 09:10:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Jds3ptMJNVtXU0ZmY1ixl0tqEhpA5hrsq7ODazIB8U8=; b=Wb0GmeR/P1ZZNy2lILDIz6KXKcGF+dKvjrQWCZErwz/N/4HcrToXy75hyhH4mmuNzAo4oE2GcgiwAQFqnQPL+GZrgtcMt3LqAa/ghecUMgGYda018ZYX5Cgdvq0tyrAcZ+m8Rujp0hSo0j5gTRGp/2ndIXNa7begW58jx5nODGM=
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.390.13; Wed, 27 Jan 2016 17:09:43 +0000
Received: from ([]) by ([]) with mapi id 15.01.0390.013; Wed, 27 Jan 2016 17:09:43 +0000
From: Antonio Sanso <>
To: John Bradley <>
Thread-Topic: [OAUTH-WG] Call for Adoption
Date: Wed, 27 Jan 2016 17:09:43 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; BY1PR0201MB1031; 5:T2xFtk1iPbmwVDMVeMThKkscKU6KamnwC0r9tuF4II6cXhUJbTYVUamLZjBDvUlIC9GDjAz4o2cQnBYrxj56OcLuhF1yqYeK6PO1Z6UDOUkUmvhKWpALFpftirphWXKkr1GR9/eRotj60D933Me2Fg==; 24:avE6qehYI8PD4mgXr9ovco9hTtZCO/gQL2OBq2RvLyfemJmjzWbO3Ojb5CT+DivY/oMn/mDJGKfr0uR5ic+8IgHIRwDMRUquAyyMzF0Jyvo=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0201MB1031;
x-ms-office365-filtering-correlation-id: 1d9588e7-9d5a-4c51-9d25-08d3273ca6bc
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY1PR0201MB1031; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0201MB1031;
x-forefront-prvs: 0834BAF534
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(479174004)(377454003)(199003)(189002)(24454002)(377424004)(2950100001)(76176999)(50986999)(86362001)(36756003)(11100500001)(5001960100002)(87936001)(66066001)(83716003)(33656002)(15975445007)(2906002)(92566002)(40100003)(3470700001)(81156007)(2900100001)(4326007)(54356999)(122556002)(5008740100001)(10090500001)(82746002)(77096005)(10400500002)(97736004)(110136002)(93886004)(5004730100002)(106116001)(3280700002)(101416001)(1096002)(19580395003)(189998001)(99286002)(19580405001)(6116002)(586003)(5002640100001)(106356001)(102836003)(105586002)(1220700001)(3846002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0201MB1031;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2016 17:09:43.5146 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0201MB1031
Archived-At: <>
Cc: "" <>
Subject: Re: [OAUTH-WG] Call for Adoption
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: Wed, 27 Jan 2016 17:10:11 -0000

hi John,

if you remember I even proposed something along those lines in Darmstadt and it was deemed (with reason) as not enough good protection since the attacker can use a proxy….



On Jan 27, 2016, at 2:30 PM, John Bradley <> wrote:

> It think requiring a common authority segment for the authorization endpoint and the token endpoint might work in common cases, but there are legitimate cases where the URI of the Authorization endpoint might be a alias in the case of multi tenants, all using a common token endpoint.    
> The larger problem would be the RS, it is not uncommon to have the AS and RS in different domains,  so with bearer tokens unless you make the same authority restriction for RS then you are not really stoping the attacker.   They can get the AT by impersonating the RS.
> I think trying to enforce a common origin policy over OAuth would be a bad direction to go.
> I understand that it seems like a easy fix on the surface, and it works for most of the things people are using OAuth for today, but would be quite limiting over the long term.
> John B.
>> On Jan 27, 2016, at 7:31 AM, wrote:
>> Hi Hans,
>> Sorry, I mixed up the IdP mix-up attack and the code phishing attack.
>> Mandating the Authorization and Token Endpoint being in the same
>> authority would solve the later without changing the wire protocol.
>> For AS mix-up attack, mandating the client to change the redirection endpoint
>> per AS would solve the problem without change the wire protocol.
>> If these are not possible, then we would have to look at changing the
>> wire protocol. The solution that solves the both cases must
>> provide the token endpoint URI authoritatively, which means
>> you have to mandate some variation of discovery mandatory.
>> Nat
>> At 2016-01-27 17:01  Hans Zandbelt wrote:
>>> I don't see how that can deal with the specific form of the attack
>>> where the Client would have sent the authorization request to the
>>> legitimate authorization endpoint of a compromised AS and believes it
>>> gets the response from that, where in fact it was redirected away to
>>> the good AS.
>>> IOW, I don't think this is so much about mixing up endpoints where to
>>> send stuff to, but mixing up the entity/endpoint from which the Client
>>> believes the response was received. That may just be terminology
>>> though.
>>> Bottom line as far as I see is that a wire protocol element in the
>>> response is needed to tell the Client who issued it, regardless of how
>>> the Client deals with configuration of the AS information.
>>> Hans.
>>> On 1/27/16 1:31 AM, Nat Sakimura wrote:
>>>> So, is there a lot of cases that the authority section of the Good AS's
>>>> Authorization Endpoint and the Token Endpoints are different?
>>>> If not, then requiring that they are the same seems to virtually remove
>>>> the attack surface for the mix-up related attacks. It does not introduce
>>>> new parameter nor discovery. If it can be done, it probably is not worth
>>>> adding a new wire protocol element to mitigate the mix-up variants.
>> _______________________________________________
>> OAuth mailing list
> _______________________________________________
> OAuth mailing list