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

John Bradley <ve7jtb@ve7jtb.com> Thu, 21 January 2016 21:50 UTC

Return-Path: <ve7jtb@ve7jtb.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1381B31B3 for <oauth@ietfa.amsl.com>; Thu, 21 Jan 2016 13:50:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60wWnrheFRsV for <oauth@ietfa.amsl.com>; Thu, 21 Jan 2016 13:50:33 -0800 (PST)
Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 256551B33B1 for <oauth@ietf.org>; Thu, 21 Jan 2016 13:50:32 -0800 (PST)
Received: by mail-qg0-x232.google.com with SMTP id 6so43345881qgy.1 for <oauth@ietf.org>; Thu, 21 Jan 2016 13:50:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Qi0fTNOpJy2SUhYbqObFCxIqzp12kdEkLPkDSiQtUCI=; b=f5LHoXW3++7mhNViIFOEazzErugGAyJ1FfiyZ41BhIiH3tbYjRlqTsXJRL9cZ63NRj c5G0NQ6hnMiAH6aBffN8i+KeAZrAyScov70n6ok/6OhL0FZ2oY3JNlcC7dwP43/fPvap mr98VNR1rCfX3gn8EKa6GUfReV4A//yWMAltQmHrKtpluvA+xynKU3I3rVt4Q4ozMGwT z/PRdeeKtSyZgeJ3pPMjRQM0PAY9jTFsZgqajG8Reqlw/2tNnlbT/w5gDGEfxSpyqgrx eqND4iVF9TKoWxZe3BASNmL3Op+trtPkiP1LhfxyOIOsB6QUZCR2uWFuwXbTCxGQdPvD VPBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Qi0fTNOpJy2SUhYbqObFCxIqzp12kdEkLPkDSiQtUCI=; b=FbGrMKTJ95Rbe07ExIwzsA6uB/7tZoUZNQIRHHrvaisGwsJYi0KUg8ZGh3yH9Cxvac ckzycncvpoHZGQmHFHYCAfWyr27+2NbJIr4aAiK5gaE9yt2bG714MX8QK85R36rbVIT5 edXyAOHkkwWqLCsJBhmCnslbovkTVSS05YFOXqwdmNZfDH0wc2lTO0SgIbTtecKuD+lL GkeyfAhkLM5t4OF59C8j8lLxGXUlEzkD9FhAnixL09A1BGFOBD32ZUn9JROCOHOw13f0 MB1m4RGvznWYBu2j6oz/pzIvKsoTDYa5Nlqgdjwca1nI3Kpl2y96xInQ3wxYjaetUYFV 0sJQ==
X-Gm-Message-State: ALoCoQkafs9xE4nOjZA5YgVGm5U/4zKp9ELBFzGpLWSphvIsdbhYuDyJDQF5ytgr5x9ZhBxfmU3jaEOpBBZu+GumkPvxuFLjHA==
X-Received: by 10.140.19.231 with SMTP id 94mr56052615qgh.32.1453413031927; Thu, 21 Jan 2016 13:50:31 -0800 (PST)
Received: from [192.168.8.101] ([181.202.192.227]) by smtp.gmail.com with ESMTPSA id t187sm1417116qht.39.2016.01.21.13.50.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jan 2016 13:50:30 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_92483AD3-CECA-42F0-8C40-89C7AA4285C0"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <2EB9855D-BAB2-4B90-B649-F1B24B8834EC@alkaline-solutions.com>
Date: Thu, 21 Jan 2016 18:50:27 -0300
Message-Id: <DC542E43-8D0B-4728-AB46-AC70F190D8AD@ve7jtb.com>
References: <BY2PR03MB442662C73E3904E73D9B9EFF5C30@BY2PR03MB442.namprd03.prod.outlook.com> <2EB9855D-BAB2-4B90-B649-F1B24B8834EC@alkaline-solutions.com>
To: David Waite <david@alkaline-solutions.com>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/5EwEtJSLRg1ZJjIgYTC2s_qXKDE>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jan 2016 21:50:38 -0000

Yes if the AS is encoding state + redirect_uri and grants in the code then it could get big.  
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.

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.

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.

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 <david@alkaline-solutions.com> 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
> 
>> On Jan 20, 2016, at 11:28 PM, Mike Jones <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>> 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:
>> ·       http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 <http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01>
>>  
>> An HTML-formatted version is also available at:
>> ·       http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html <http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html>
>>  
>>                                                           -- Mike
>>  
>> P.S.  This note was also posted at http://self-issued.info/?p=1526 <http://self-issued.info/?p=1526> and as @selfissued <https://twitter.com/selfissued>.
>>  
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth