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

"Phil Hunt (IDM)" <phil.hunt@oracle.com> Tue, 26 January 2016 22:00 UTC

Return-Path: <phil.hunt@oracle.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 19E451B3201 for <oauth@ietfa.amsl.com>; Tue, 26 Jan 2016 14:00:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 2KuFa-zKo4f3 for <oauth@ietfa.amsl.com>; Tue, 26 Jan 2016 14:00:52 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE0F31A1A4F for <oauth@ietf.org>; Tue, 26 Jan 2016 14:00:51 -0800 (PST)
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u0QM0omo004948 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Jan 2016 22:00:50 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u0QM0nTQ011005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 26 Jan 2016 22:00:50 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u0QM0nlB000500; Tue, 26 Jan 2016 22:00:49 GMT
Received: from [25.174.19.227] (/24.114.40.201) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 26 Jan 2016 14:00:49 -0800
Content-Type: multipart/alternative; boundary=Apple-Mail-DDB44199-F5B9-4754-A5F9-45D74D7946EA
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" <phil.hunt@oracle.com>
X-Mailer: iPhone Mail (13D15)
In-Reply-To: <56A7D29F.2080701@lodderstedt.net>
Date: Tue, 26 Jan 2016 14:00:41 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <E12AC47E-3000-4FB2-8E9D-FA4C63760808@oracle.com>
References: <BY2PR03MB442662C73E3904E73D9B9EFF5C30@BY2PR03MB442.namprd03.prod.outlook.com> <56A7D29F.2080701@lodderstedt.net>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
X-Source-IP: aserv0022.oracle.com [141.146.126.234]
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/cS9kR5pwtJompsndnAbeazwaiJQ>
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: Tue, 26 Jan 2016 22:00:54 -0000

Agreed. 

The security ext draft might fit well with the general grab bag of issues around all the "dynamic" cases. 

It would be stronger than a new threat model ext draft which would likely be informational. 

Phil

> On Jan 26, 2016, at 12:10, Torsten Lodderstedt <torsten@lodderstedt.net>; wrote:
> 
> 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 [I‑D.bradley‑oauth‑jwt‑encoded‑state]    
>          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,
> Torsten.
> 
> 
>> 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:
>> ·       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
>>  
>>                                                           -- Mike
>>  
>> P.S.  This note was also posted at http://self-issued.info/?p=1526 and as @selfissued.
>>  
>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth