Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft
William Denniss <wdenniss@google.com> Fri, 22 January 2016 13:11 UTC
Return-Path: <wdenniss@google.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 8E02B1A21BE for <oauth@ietfa.amsl.com>; Fri, 22 Jan 2016 05:11:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
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 LHU3D8NnIo9c for <oauth@ietfa.amsl.com>; Fri, 22 Jan 2016 05:11:35 -0800 (PST)
Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (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 97CB61A21C3 for <oauth@ietf.org>; Fri, 22 Jan 2016 05:11:35 -0800 (PST)
Received: by mail-ob0-x236.google.com with SMTP id vt7so61984751obb.1 for <oauth@ietf.org>; Fri, 22 Jan 2016 05:11:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=z4Dh0bZZ+YHT6s7zgY/VFVYXKye2ZQ28uWCrw9hKcsU=; b=IVbtu6iNLH/A9UCRi1/q1eULPlE3kM4Q+k1BegXEewFo9vUlFfeOd2KNu24gj+fCbN imv+pW8WJKS0+Xa4l08AEstH6rRzgQRWuGqqCH43N4VhiZ6RJ87hmj8QjQ3S803T1Ny0 1BvEyp005m5mC5q2URa0i9ORux5VPW5EJX7P5Tp1hqkdgWITliGbHzCx5yMR6ztS4Z7g LCyjVKMTtiTzqGqvlG2QbDdx36rnsVtDssqE/sW9VaD8GMquScaSJ3wQg/kI8G++1RVE rL4SdkpZWRio6BWBLfoMDJUR6kk/8LYzcVt1vCZAz9khwwJpLKoU92+fxi7grS3Ww2OA WmDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=z4Dh0bZZ+YHT6s7zgY/VFVYXKye2ZQ28uWCrw9hKcsU=; b=ROmVznFHH7MhxFPwSEeQCGst6GbFnoyY8K+j0Khj09AVWNEXS7R2rmHwmIPABfx7m0 PSl4Lx59200VNEqU5ewcTReQGsUFzsN18xNmd8cuVdUqHoX283NSIJUBbRxrxEvCL/PA EHVvBvB92APiHzZkfnTHalvT8eN4mT4/xxoxdFVOvmidO1XQWOJR9iWAU0/Ah9n0f2pG HrTU62dt98aMoW0wVgYFfhyCnbU8d/uWKvwvVZW3R/4s61kyCayuYCBptvjtYbik0CTc bSO7pXH8hKxbIVghYrlHnUO2qJJs+vQxiSc7n4CBqJ2RERqJ1zxIpqUNFyhNfpFkitU4 QiYg==
X-Gm-Message-State: AG10YOQMx3lIYp5cBhQcoXLn0qcUaOzi0uoyIvu/DstiQwAIK3vzJRe01pWEPQllDYoEk5daYh+eyMq4vh52jQzT
X-Received: by 10.182.214.40 with SMTP id nx8mr2397769obc.20.1453468294832; Fri, 22 Jan 2016 05:11:34 -0800 (PST)
MIME-Version: 1.0
References: <BY2PR03MB442662C73E3904E73D9B9EFF5C30@BY2PR03MB442.namprd03.prod.outlook.com> <2EB9855D-BAB2-4B90-B649-F1B24B8834EC@alkaline-solutions.com> <DC542E43-8D0B-4728-AB46-AC70F190D8AD@ve7jtb.com> <80218A07-9D37-42A3-B90A-56AEDBC3A86C@alkaline-solutions.com> <CAANoGhJT8j0ZO09kBJHpg+QVkFi-RuoA42Rb+zd698aC9AmLUw@mail.gmail.com>
In-Reply-To: <CAANoGhJT8j0ZO09kBJHpg+QVkFi-RuoA42Rb+zd698aC9AmLUw@mail.gmail.com>
From: William Denniss <wdenniss@google.com>
Date: Fri, 22 Jan 2016 13:11:24 +0000
Message-ID: <CAAP42hCzVtXiECAZzaU-YEQe01BPbOc6OTL-u=PLQkxdsYeSfQ@mail.gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>, David Waite <david@alkaline-solutions.com>
Content-Type: multipart/alternative; boundary="e89a8ff1c01e6842e40529ebf55c"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/Hu0VVNOiN9WLFuN8jvfBHTvOW9Q>
Cc: IETF oauth WG <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: Fri, 22 Jan 2016 13:11:37 -0000
+1 ;) On Fri, Jan 22, 2016 at 8:45 PM John Bradley <ve7jtb@ve7jtb.com> wrote: > Perhaps Frankenstein response is a better name than cut and paste attack. > > John B. > On Jan 22, 2016 1:22 AM, "David Waite" <david@alkaline-solutions.com> > wrote: > >> On Jan 21, 2016, at 2:50 PM, John Bradley <ve7jtb@ve7jtb.com> wrote: >> >> 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. >> >> Yes, true. >> >> >> 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. >> >> I think I understand what you are saying. Someone won’t be able to >> frankenstein up a state and a token from two different responses from an >> AS, and have a client successfully fetch an access token based on the >> amalgamation. >> >> >> 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. >> >> Yes, if a party intercepts the redirect_url, or the AS fails to enforce >> one time use (which even for a compliant implementation could just mean the >> attacker was faster than the state propagated within the AS) >> >> Makes sense. Thanks John. >> >> -DW >> >> 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 >> >> _______________________________________________ > 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)