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
https://www.ietf.org/mailman/listinfo/oauth
--
Chief Architect
Identity Services Engineering Work: 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
