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

[Sergey Beryozkin <[e-mail]>]

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:[e-mail]]
> *Sent:* Monday, January 11, 2016 10:21 AM
> *To:* Mike Jones <[e-mail]>; [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]>
>
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> --
>
> Chief Architect
>
> Identity Services Engineering     Work:[e-mail] <mailto:[e-mail]>
>
> AOL Inc.                          AIM:  gffletch
>
> Mobile: [phone]           Twitter:http://twitter.com/gffletch
>
> Office: [phone]           Photos:http://georgefletcher.photography
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
Sergey Beryozkin

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