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

John Bradley <ve7jtb@ve7jtb.com> Fri, 22 January 2016 18:57 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 17D521B2C16 for <oauth@ietfa.amsl.com>; Fri, 22 Jan 2016 10:57:16 -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 T3prLwcFbeXM for <oauth@ietfa.amsl.com>; Fri, 22 Jan 2016 10:57:13 -0800 (PST)
Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 0E4CE1B2C13 for <oauth@ietf.org>; Fri, 22 Jan 2016 10:57:12 -0800 (PST)
Received: by mail-qk0-x235.google.com with SMTP id s5so32283907qkd.0 for <oauth@ietf.org>; Fri, 22 Jan 2016 10:57:12 -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=uO2AIHl8jqLEMr7nuciJDjF9ER55vnqq0urLzaqcZUA=; b=CNAXSECO5LHO1Z2WmioXg4sZ2WtPpdeAOY4SrzAQH7ItS+afD6QI6GUx/siHb2rI1c LUZ0l+pYW26Ezp0qi8pfjly4BqkZPG31VuyVkmIbrVBmZGTP1CvbVfES9v2WsKyQK4B7 7nai30VZo6YWM/3WCwi4GLvr38PBVZbOG2s/O8XOKpoMn8+livXF8Ez9jhGhQh7ZdcjP 6YwOD18Qq4l837BUazuEgo1CTDqlu/tq0n/fBBs0X2wK2/IS7calj006NKRMACdfKZy4 ztsbESqV+i3rugopU//oGj9RQgpLx6u3UDR3qNsmb2xt/1OtfGrtCijVJgzRWV4xcjeN uA+A==
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=uO2AIHl8jqLEMr7nuciJDjF9ER55vnqq0urLzaqcZUA=; b=UKqQlKjumAhpyGIPH/6/5qR8wXIhwPdILbpM7Ory2zenpByYZwsiY37HqSl5UUCo9Z TiobntDOckdL4F0y/ZdiQk4WSEs0nuLoPw8Boaos7Ba/afvCOE3e2ZwB2PNacpbDWAL9 vhwkrhdgO7jfHxmuUb1Z9hRwdZOPG4/aTLqnyt7NcIUFYdKHqSDxk+0d2G47xU4O0kx2 FYNnhGnyuA/IxyysTEXUj7RwZ2NXJyFi4srGdy6CjbxoBIXa9sjF7QUArezqOcsAwUWO CQO3c6OEfaVXGlLygQMI5HOEWwMhiqKzOHCx5ZlnfUKKwy+fyTEaB7srVkap8uBevm0O AbMw==
X-Gm-Message-State: AG10YOSmpXMX1Dx9D+r81nY1NdI1qC5huzll5qPpo+kcdg3AESXYrZWZhnLYUSiIQcsDNg==
X-Received: by 10.55.77.216 with SMTP id a207mr5727402qkb.80.1453489032059; Fri, 22 Jan 2016 10:57:12 -0800 (PST)
Received: from [192.168.8.100] ([181.202.234.84]) by smtp.gmail.com with ESMTPSA id 75sm3337816qkw.19.2016.01.22.10.57.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 22 Jan 2016 10:57:11 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_15D6CBDD-FC80-453E-8E89-312FD8DD08A3"; 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: <478C8683-0E47-43E7-A7F3-75F89AB1DCDA@alkaline-solutions.com>
Date: Fri, 22 Jan 2016 15:57:08 -0300
Message-Id: <EB5584D0-33AD-4CEB-8A51-D30A4D57B7BE@ve7jtb.com>
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> <CAAP42hCzVtXiECAZzaU-YEQe01BPbOc6OTL-u=PLQkxdsYeSfQ@mail.gmail.com> <56A260B6.4060302@aol.com> <478C8683-0E47-43E7-A7F3-75F89AB1DCDA@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/ZAbL-UHjFHKVZVab5gcMKt9cMS0>
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 18:57:16 -0000

Now that we have a cool name all we need is a logo for the attack and per haps an anime character, and we are done with all the hard work:)

John B.
> On Jan 22, 2016, at 2:54 PM, David Waite <david@alkaline-solutions.com> wrote:
> 
> It’s pronounced FronkenSTEEN-ian.
> 
> -DW
> 
>> On Jan 22, 2016, at 10:02 AM, George Fletcher <gffletch@aol.com <mailto:gffletch@aol.com>> wrote:
>> 
>> "Frankensteinian Amalgamation" -- David Waite
>> 
>> I like it! :)
>> 
>> On 1/22/16 8:11 AM, William Denniss wrote:
>>> +1 ;)
>>> On Fri, Jan 22, 2016 at 8:45 PM John Bradley < <mailto:ve7jtb@ve7jtb.com>ve7jtb@ve7jtb.com <mailto: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 <mailto:david@alkaline-solutions.com>> wrote:
>>>> On Jan 21, 2016, at 2:50 PM, John Bradley < <mailto:ve7jtb@ve7jtb.com>ve7jtb@ve7jtb.com <mailto: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 <mailto: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 <mailto:OAuth@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>> 
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>> -- 
>> Chief Architect                   
>> Identity Services Engineering     Work: george.fletcher@teamaol.com <mailto:george.fletcher@teamaol.com>
>> AOL Inc.                          AIM:  gffletch
>> Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch <http://twitter.com/gffletch>
>> Office: +1-703-265-2544           Photos: http://georgefletcher.photography <http://georgefletcher.photography/>
>