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

[Mike Jones <[e-mail]>]

Sorry to be slow responding, Nov.  I wanted to wait to respond until a draft with the “state” token request parameter was published, which just happened.

I think the oauth-meta spec solves some of them but not others.  There were a bunch of different attacks discussed by the security researchers in Darmstadt (see the notes at https://docs.google.com/document/d/136Cz2iwUFMdoKWZPCqZRhkmfmHAlJ6kM5OyeXzGptU4/edit#heading=h.od92ummd22zs), some with interdependencies between them.  There are reasons, for instance, for sending the “state” value to the token endpoint so that the authorization server can check it.  The mitigations involve validations by both the client and the server – not all of which the oauth-meta draft includes.

Also, see the current discussion in the thread “[OAUTH-WG] Call for Adoption”.  In short, I think there should be one solution approach that we work on for this, not two.

                                                Best wishes,
                                                -- Mike

From: nov matake [mailto:[e-mail]]
Sent: Monday, January 11, 2016 10:45 PM
To: Mike Jones <[e-mail]>
Cc: Hans Zandbelt <[e-mail]>; George Fletcher <[e-mail]>; [e-mail]
Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

Hi Mike,

Isn’t Nat’s "OAuth Response Metadata” spec enough to solve those issues?
https://tools.ietf.org/id/draft-sakimura-oauth-meta-05.txt

On Jan 12, 2016, at 05:40, Mike Jones <[e-mail]<mailto:[e-mail]>> wrote:

The specification describes this validation method (comparison of the issuer received to the issuer recorded at registration time) in step 2 of Section 4 (Validating the Response).  In fact, I added this in response to your feedback on an earlier draft, Hans.

-----Original Message-----
From: Hans Zandbelt [mailto:[e-mail]]
Sent: Monday, January 11, 2016 12:34 PM
To: Mike Jones <[e-mail]<mailto:[e-mail]>>; George Fletcher <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
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 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:[e-mail]]
*Sent:* Monday, January 11, 2016 12:13 PM
*To:* Mike Jones <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
*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:[e-mail]]
   *Sent:* Monday, January 11, 2016 10:21 AM
   *To:* Mike Jones <[e-mail]<mailto:[e-mail]>>
   <mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
   <mailto:[e-mail]>
   *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

       [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>

       https://www.ietf.org/mailman/listinfo/oauth




   --

   Chief Architect

   Identity Services Engineering     Work:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>

   AOL Inc.                          AIM:  gffletch

   Mobile: [phone]           Twitter:http://twitter.com/gffletch

   Office: [phone]           Photos:http://georgefletcher.photography<http://georgefletcher.photography/>



--

Chief Architect

Identity Services Engineering     Work:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>

AOL Inc.                          AIM:  gffletch

Mobile: [phone]           Twitter:http://twitter.com/gffletch

Office: [phone]           Photos:http://georgefletcher.photography<http://georgefletcher.photography/>



_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth

--
Hans Zandbelt              | Sr. Technical Architect
[e-mail]<mailto:[e-mail]> | Ping Identity

_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth