From: Mike Jones <Michael.Jones@microsoft.com>
To: Hans Zandbelt <hzandbelt@pingidentity.com>, George Fletcher
 <gffletch@aol.com>, "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation
Thread-Index: AdFMSEdeh3slUb5fSSeAYII0TkfznQAVH34AAALUM/AAARo6AAAACUsAAACxt4AAABX4UA==
Date: Mon, 11 Jan 2016 20:40:53 +0000
Message-ID: <BY2PR03MB442AA14A823722758AACCD0F5C90@BY2PR03MB442.namprd03.prod.outlook.com>
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>
 <569411BF.5090500@pingidentity.com>
In-Reply-To: <569411BF.5090500@pingidentity.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: microsoft.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2016 20:40:53.3182 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/cYum6WmlC27W4VRxjSNqHaakDXg>
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:41:18 -0000

The specification describes this validation method (comparison of the issue=
r received to the issuer recorded at registration time) in step 2 of Sectio=
n 4 (Validating the Response).  In fact, I added this in response to your f=
eedback on an earlier draft, Hans.

-----Original Message-----
From: Hans Zandbelt [mailto:hzandbelt@pingidentity.com]=20
Sent: Monday, January 11, 2016 12:34 PM
To: Mike Jones <Michael.Jones@microsoft.com>; George Fletcher <gffletch@aol=
.com>; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

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 informatio=
n anyhow and they just need to confirm that the issuer value received in th=
e 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>; 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=3D, state=3D and jwt=
=3D (?)
> or individually iss=3D and aud=3D 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 correc=
t.
>
> 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/JIVxFBGsJBVtm7ljwJhP=
Um3Fr-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=3D1496>) so that the client can verif=
y
>         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-0=
0
>
>         An HTML-formatted version is also available at:
>
>         *http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation=
-00.html
>
>                                                                    -- Mik=
e
>
>         P.S.  This note was also posted at
>         http://self-issued.info/?p=3D1524 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 <m=
ailto: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.photog=
raphy
>
>
>
> --
>
> Chief Architect
>
> Identity Services Engineering     Work:george.fletcher@teamaol.com <mailt=
o: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.photograph=
y
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--=20
Hans Zandbelt              | Sr. Technical Architect
hzandbelt@pingidentity.com | Ping Identity