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

Hans Zandbelt <hzandbelt@pingidentity.com> Mon, 11 January 2016 20:34 UTC

Return-Path: <hzandbelt@pingidentity.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 A28011A910F for <oauth@ietfa.amsl.com>; Mon, 11 Jan 2016 12:34:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 WrbXbwaFAu3H for <oauth@ietfa.amsl.com>; Mon, 11 Jan 2016 12:34:13 -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 DAB841A910E for <oauth@ietf.org>; Mon, 11 Jan 2016 12:34:12 -0800 (PST)
Received: by mail-ob0-x236.google.com with SMTP id ba1so417770353obb.3 for <oauth@ietf.org>; Mon, 11 Jan 2016 12:34:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=4z0BIKLl2QXRasCKN0SeyPw7fr/ccPKFtX5ujRtmvtI=; b=Z/AarIIb1VjbV3T6JclrUK8X9MgtxvQxC2mAL9ZyFRhFEmHHSE1BBH5PK0DEUaEkrb cIQ8BIVEf5U1g9gh4bTqXES3MAOdBqRlvmWG2v5li60D6PvHt9vv/C4zZokGjUG89SVJ tCsK8nBVzvias/9+WYsYpxU5gkeJqfTIvoHOk=
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=4z0BIKLl2QXRasCKN0SeyPw7fr/ccPKFtX5ujRtmvtI=; b=GYEeWRHXT6QMs3ysfx/MLdv8reRxluCoST5ewGIaENAEUPr2rs+x+qvTTKjigpZi61 182Y/G7V0VwFYsM/g9hPRz4xAOZjHSVFVKy3ZErhMC+kRNk9E8z7eVHMQoz71Zlt2gzP roeNZ5f7n2Hkq7aTvY4XkEI3WHUe0/U3lxmAE7UPj9DJ12PM5udRFlwFvy0uNkg1T46/ Q9RzQWhz+YUFcirePezRTkkbJ6bRlp/GG80sSOopUIKif4FyTdX6Zyb3FphJpd71dYHY A5YcrYSrRpAVXxeSK5JfD8zGPRCE5uzrx3e9bvnhITWdW3OFZj9SnS9LoFdGBx2mKFOy /9og==
X-Gm-Message-State: ALoCoQlXNsAAWrBz8bz589PS1D5MrW/vEnRT3jKv44mxx2EFfxzx/Q1JtY5e+0swaKKzRLoZSfQdKwxc9qoj+SYoQPRjdn52TQ==
X-Received: by 10.60.65.10 with SMTP id t10mr15956795oes.10.1452544451432; Mon, 11 Jan 2016 12:34:11 -0800 (PST)
Received: from [10.1.2.108] ([205.169.68.218]) by smtp.gmail.com with ESMTPSA id mm4sm52306143obb.1.2016.01.11.12.34.08 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Jan 2016 12:34:10 -0800 (PST)
To: Mike Jones <Michael.Jones@microsoft.com>, George Fletcher <gffletch@aol.com>, "oauth@ietf.org" <oauth@ietf.org>
References: <BY2PR03MB442D5C13C5157A506DAC9B0F5C90@BY2PR03MB442.namprd03.prod.outlook.com> <5693F276.8020501@aol.com> <BY2PR03MB442C71F1A51D05DD7390ABAF5C90@BY2PR03MB442.namprd03.prod.outlook.com> <56940CD8.8000701@aol.com> <BY2PR03MB44280090C70D477698D3B7BF5C90@BY2PR03MB442.namprd03.prod.outlook.com>
From: Hans Zandbelt <hzandbelt@pingidentity.com>
Message-ID: <569411BF.5090500@pingidentity.com>
Date: Mon, 11 Jan 2016 13:34:07 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <BY2PR03MB44280090C70D477698D3B7BF5C90@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/JVrd6r4_YlFMaxDDWCqXPa72xIE>
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: Mon, 11 Jan 2016 20:34:15 -0000

I disagree that validating endpoints "at this step" (which refers to 
right before making the token request) should be the default way of 
handling this. The vast majority of OAuth client deployments connecting 
to more than one AS will have a static configuration of the ASes 
issuer/endpoint information anyhow and they just need to confirm that 
the issuer value received in the authorization response is the same 
issuer as that the request was sent to.

Hans.

On 1/11/16 1:14 PM, Mike Jones wrote:
> Correct
>
> *From:*George Fletcher [mailto:gffletch@aol.com]
> *Sent:* Monday, January 11, 2016 12:13 PM
> *To:* Mike Jones <Michael.Jones@microsoft.com>om>; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation
>
> So just to make sure I understand...
>
> This specification requires the response from the Authorization Server
> to an successful /authorize call to pass back code=, state= and jwt= (?)
> or individually iss= and aud= as URL parameters on the 302 to the
> redirect_url. This way, before the client issues a call to the /token
> endpoint (with the code), it can verify that the token endpoint is correct.
>
> If the client doesn't validate the endpoints at this step, then it could
> disclose it's secret to a malicious endpoint. Correct?
>
> Thanks,
> George
>
> On 1/11/16 2:59 PM, 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).
>
>     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>
>     <mailto:Michael.Jones@microsoft.com>; oauth@ietf.org
>     <mailto: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
>
>
>
> --
>
> 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
>

-- 
Hans Zandbelt              | Sr. Technical Architect
hzandbelt@pingidentity.com | Ping Identity