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:gffle...@aol.com]
*Sent:* Monday, January 11, 2016 10:21 AM
*To:* Mike Jones <michael.jo...@microsoft.com>; 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
