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

Sergey Beryozkin <sberyozkin@gmail.com> Thu, 21 January 2016 11:47 UTC

Return-Path: <sberyozkin@gmail.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 A17941A8A76 for <oauth@ietfa.amsl.com>; Thu, 21 Jan 2016 03:47:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level:
X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, 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 izavv5pPcndE for <oauth@ietfa.amsl.com>; Thu, 21 Jan 2016 03:47:30 -0800 (PST)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 51C6D1A8A6B for <oauth@ietf.org>; Thu, 21 Jan 2016 03:47:30 -0800 (PST)
Received: by mail-wm0-x22e.google.com with SMTP id 123so170647363wmz.0 for <oauth@ietf.org>; Thu, 21 Jan 2016 03:47:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=rGosaEtsoFSbg1zndHaIrNPsmJmP1vseEjXa/7Yp4+Q=; b=hGZ7F39fwJ3CB65YL6Fnc6Q6DKm7immqRhO7WQXACf3V5G6pXla3ahK9wMhYd4HLgi 6QVD5w4wzYg/GejF8eeonMlFbICWE4Qb8eD/b2AnI9TYvdFlJV/oZNAwG1E9glWrW9+H buFDX1tkRA1ftgwPe3Bw1JfkuAVzocgBSsNRS4t57+mCn5E1qtsnKSE7X+cjAY8s97Ww 94Ar85xrKm7GFKgnmHaSVb0jBvveSsNhS716UvLUi8VCCnp6DuT3IgHNGC1gBpFYspjB ILALFF+5LDEZ7lfb8TUE1+54ZR5rZNkX5Xik0hdaKRQpfFuTSo3VnoqO5BpPPcgwfkhy /KtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=rGosaEtsoFSbg1zndHaIrNPsmJmP1vseEjXa/7Yp4+Q=; b=BDaysOXL+aA4CZ9XzucNeiLM5c2mESqlcLAB31BZIS/2Orz3Q46k8kKPccUjvvAhem WKdozyWkBn2R/OcMBt6dACIVEqxNSuSY9DVGDvCndgc5vm1h0aFfmagR2rgnOPmvPwlS Wp39jte8i3YoEMTOrJUN2B9VVhf550RT+mo//wTju7GDqSPzt21zvrMc4d4F4g3UEcfj ni5Bk/l6d/G9rz6PCFzMRGRYFy+ey1i1SVTZnIJBTZ9OItMY1U98blV07grl/Ra0zP+y lqnPYhg7juT4KNBoK+llcg61wPlZfc91WPfYuqt7SjYkwAHGYRt5ZQF2Jhfcjsvxaner 3Mqg==
X-Gm-Message-State: ALoCoQkmu2Ctq5TG8GYAGvsK501TaIPXkge+5omggs/PiKudAxSnwarRaaEgd+jCk/c5zwQLysaksSArJo1sj+6R4ZKYFaErAg==
X-Received: by 10.194.158.73 with SMTP id ws9mr47457446wjb.40.1453376848854; Thu, 21 Jan 2016 03:47:28 -0800 (PST)
Received: from [192.168.2.7] ([5.179.70.21]) by smtp.googlemail.com with ESMTPSA id yz5sm1078416wjc.36.2016.01.21.03.47.27 for <oauth@ietf.org> (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Jan 2016 03:47:27 -0800 (PST)
To: oauth@ietf.org
References: <BY2PR03MB442D5C13C5157A506DAC9B0F5C90@BY2PR03MB442.namprd03.prod.outlook.com> <5693F276.8020501@aol.com> <BY2PR03MB442C71F1A51D05DD7390ABAF5C90@BY2PR03MB442.namprd03.prod.outlook.com>
From: Sergey Beryozkin <sberyozkin@gmail.com>
Message-ID: <56A0C54F.7080501@gmail.com>
Date: Thu, 21 Jan 2016 11:47:27 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <BY2PR03MB442C71F1A51D05DD7390ABAF5C90@BY2PR03MB442.namprd03.prod.outlook.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/NVcNFJPtcx94FJdL_Efu_3Iw1ic>
Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation
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 11:47:32 -0000

Hi

On 11/01/16 19:59, Mike Jones wrote:
> The alternatives for the code flow are to return them either in a new
> JWT added to the reply containing them in the “iss” and “aud” claims or
> to return them in new individual “client_id” and “iss” authorization
> response parameters.  Both alternatives are described in the draft.  I’m
> sure that we’ll now be having a good engineering discussion on the
> tradeoffs between the alternatives.,
>
> In a separate draft, John Bradley will shortly also be describing the
> possibility of securing the “state” value using a “state_hash” value
> that works in a way that’s similar to how “at_hash” and “c_hash” secure
> the “access_token” and “code” values in Connect.  This would be an
> alternative means of binding the authorization request and response to
> the session – accomplishing the same thing that the Connect “nonce” does.
>
> While I fully get that some OAuth implementations want to avoid having
> to have crypto, it seems like at least support for cryptographic hashing
> (SHA-256, etc.) may be necessary to mitigate some of these attacks (at
> least for clients that use more than one authorization server).
>

I'm not sure if it is relevant or misses the point, if so then my 
apologies, but I guess it is +1 to the *optional* hashing of the *whole* 
response as opposed to of some individual response properties. Awhile 
back I posted some proposal to use a JWK thumbprint idea to calculate a 
thumbprint of the response and sign in and include the result of it as 
an extra response property.

Cheers, Sergey


> The other important engineering discussion I know we’re going to have is
> whether, when an OAuth profile already returns the information needed
> for the mitigation, whether we want to specify that the client obtain it
> from the existing location, or whether to also return it in a duplicate
> location.  I’ll note that OpenID Connect already returns the client ID
> and issuer for the flows that return an ID Token in the authorization
> response, so this isn’t a hypothetical question.
>
> Finally, I know that we’ll need to discuss the impact of cut-and-paste
> attacks when the issuer and client ID are returned as individual
> authorization response parameters that are not cryptographically bound
> to the rest of the response. The cut-and-paste attack that returning the
> issuer and client_id values as separate parameters enables, even when
> state_hash or nonce is used, is for the attacker to capture the
> legitimate response containing “iss” and “client_id” results and
> substitute different values for these fields, then post that altered
> response to the legitimate client.  The state and/or nonce values are
> protected against substitution but “iss” and “client_id” are not.
>
> And yes, I absolutely agree that good examples are essential.  That’s
> high on my list for the -01 version.
>
>                                                            Thanks a bunch,
>
>                                                            -- Mike
>
> *From:*George Fletcher [mailto:gffletch@aol.com]
> *Sent:* Monday, January 11, 2016 10:21 AM
> *To:* Mike Jones <Michael.Jones@microsoft.com>om>; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation
>
> Thanks Mike. One question after reading about the different attack
> vectors and this spec...
>
> How are the 'iss' and 'aud' values returned with the 'code' and 'state'
> parameters. It seems the client needs to verify the endpoints before
> making the request to exchange the code for a token. If the client is
> using the default OAuth2 client_id and client_secret these values will
> be sent to the malicious endpoint if the client can't verify the
> endpoints before hand.
>
> Also, it would be nice to add some non-normative examples to the spec.
>
> Thanks,
> George
>
> On 1/11/16 4:27 AM, Mike Jones wrote:
>
>     Yesterday Hannes Tschofenig announced an OAuth Security Advisory on
>     Authorization Server Mix-Up
>     <https://mailarchive.ietf.org/arch/msg/oauth/JIVxFBGsJBVtm7ljwJhPUm3Fr-w>.
>     This note announces the publication of the strawman OAuth 2.0 Mix-Up
>     Mitigation draft he mentioned that mitigates the attacks covered in
>     the advisory.  The abstract of the specification is:
>
>     This specification defines an extension to The OAuth 2.0
>     Authorization Framework that enables an authorization server to
>     provide a client using it with a consistent set of metadata about
>     itself. This information is returned in the authorization response.
>     It can be used by the client to prevent classes of attacks in which
>     the client might otherwise be tricked into using inconsistent sets
>     of metadata from multiple authorization servers, including
>     potentially using a token endpoint that does not belong to the same
>     authorization server as the authorization endpoint used. Recent
>     research publications refer to these as "IdP Mix-Up" and "Malicious
>     Endpoint" attacks.
>
>     The gist of the mitigation is having the authorization server return
>     the client ID and its issuer identifier (a value defined in the
>     OAuth Discovery specification <http://self-issued.info/?p=1496>) so
>     that the client can verify that it is using a consistent set of
>     authorization server configuration information, that the client ID
>     is for that authorization server, and in particular, that the client
>     is not being confused into sending information intended for one
>     authorization server to a different one.  Note that these attacks
>     can only be made against clients that are configured to use more
>     than one authorization server.
>
>     Please give the draft a quick read and provide feedback to the OAuth
>     working group.  This draft is very much a starting point intended to
>     describe both the mitigations and the decisions and analysis
>     remaining before we can be confident in standardizing a solution.
>     Please definitely read the Security Considerations and Open Issues
>     sections, as they contain important information about the choices
>     made and the decisions remaining.
>
>     Special thanks go to Daniel Fett (University of Trier), Christian
>     Mainka (Ruhr-University Bochum), Vladislav Mladenov (Ruhr-University
>     Bochum), and Guido Schmitz (University of Trier) for notifying us of
>     the attacks and working with us both on understanding the attacks
>     and on developing mitigations.  Thanks too to Hannes Tschofenig for
>     organizing a meeting on this topic last month and to Torsten
>     Lodderstedt and Deutsche Telekom for hosting the meeting.
>
>     The specification is available at:
>
>     ·http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00
>
>     An HTML-formatted version is also available at:
>
>     ·http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-00.html
>
>                                                                -- Mike
>
>     P.S.  This note was also posted at http://self-issued.info/?p=1524
>     and as @selfissued <https://twitter.com/selfissued>.
>
>
>
>
>     _______________________________________________
>
>     OAuth mailing list
>
>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>
>     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
>
> Office: +1-703-265-2544           Photos:http://georgefletcher.photography
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/