Correct
From: George Fletcher [mailto:gffle...@aol.com]
Sent: Monday, January 11, 2016 12:13 PM
To: Mike Jones <michael.jo...@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=, 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:gffle...@aol.com]
Sent: Monday, January 11, 2016 10:21 AM
To: Mike Jones
<michael.jo...@microsoft.com><mailto:michael.jo...@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.fletc...@teamaol.com<mailto:george.fletc...@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.fletc...@teamaol.com<mailto:george.fletc...@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
