Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft
Torsten Lodderstedt <torsten@lodderstedt.net> Tue, 26 January 2016 20:10 UTC
Return-Path: <torsten@lodderstedt.net>
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 DEF621A00CA for <oauth@ietfa.amsl.com>; Tue, 26 Jan 2016 12:10:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.251
X-Spam-Level:
X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 fxgfmWl-CSFE for <oauth@ietfa.amsl.com>; Tue, 26 Jan 2016 12:10:22 -0800 (PST)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) (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 10F461B2C5B for <oauth@ietf.org>; Tue, 26 Jan 2016 12:10:22 -0800 (PST)
Received: from [79.218.87.147] (helo=[192.168.71.102]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <torsten@lodderstedt.net>) id 1aO9wP-0003Jm-Cq; Tue, 26 Jan 2016 21:10:17 +0100
To: Mike Jones <Michael.Jones@microsoft.com>, "oauth@ietf.org" <oauth@ietf.org>
References: <BY2PR03MB442662C73E3904E73D9B9EFF5C30@BY2PR03MB442.namprd03.prod.outlook.com>
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-ID: <56A7D29F.2080701@lodderstedt.net>
Date: Tue, 26 Jan 2016 21:10:07 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <BY2PR03MB442662C73E3904E73D9B9EFF5C30@BY2PR03MB442.namprd03.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------070202000207060400050100"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/1-jYvN0SYXMB0Ow1xmZmir7vNS8>
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 20:10:28 -0000
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 athttp://self-issued.info/?p=1526 and > as @selfissued <https://twitter.com/selfissued>. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Dra… Mike Jones
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… John Bradley
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… Justin Richer
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… John Bradley
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… Justin Richer
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… Hans Zandbelt
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… Justin Richer
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… David Waite
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… John Bradley
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… David Waite
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… John Bradley
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… William Denniss
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… Thomas Broyer
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… John Bradley
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… George Fletcher
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… David Waite
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… John Bradley
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… Paul Madsen
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… George Fletcher
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… Roland Hedberg
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… George Fletcher
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… Torsten Lodderstedt
- Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation… Phil Hunt (IDM)