In November 2015 the OAuth WG chairs had been informed about new attacks against OAuth clients using multiple authorization servers. Such a setup may exist in OAuth as well as in OpenID Connect. To discuss the details of the (not yet published) attacks a small group met at Deutsche Telekom in Darmstadt/Germany in December and brainstormed about mitigation techniques.
On a high-level the attack can be described as an OAuth / OpenID Connect client that gets confused about which authorization server (AS) issued tokens, which leads to a failure in authentication and authorization. Details about the attack can be found at http://arxiv.org/abs/1601.01229 and http://arxiv.org/pdf/1508.04324.pdf. As a quick and immediate self-mitigation, which requires manual configuration, a client that has client ids issued by more than one AS MUST register a "redirect_uri" value with each AS containing a distinct AS specific component. Client implementations must verify that the AS specific component received in the authorization response correlates with state information stored internally at the client for that request. If the authorization response does not contain the anticipated AS-specific component then it MUST be rejected. A strawman proposal for a protocol-based mitigation technique that relies on a new issuer parameter within the authorization response will be submitted to the OAuth working group in the next few days. We encourage the OAuth WG members to carefully study the attack and the proposed mitigation mechanism. We believe that the working group should standardize a solution with high priority and therefore ask for feedback by January 31st 2016. The solution technique will be developed within the IETF OAuth working group using our regular working group process. The chairs would like to thank Guido Schmitz (University of Trier), Daniel Fett (University of Trier), Christian Mainka (Ruhr-University Bochum) and Vladislav Mladenov (Ruhr-University Bochum) for contacting us and for providing us a possibility to investigate the attack and to develop mitigation techniques. We would also like to thank Torsten Lodderstedt (from Deutsche Telekom) for hosting our meeting. Receiving security review from the research community helps to improve the quality of our protocols. We anticipate a much closer working relationship with these research groups to tackle potential security issues before the publication of our specifications as finished RFCs. To make it easier to contact our working group for security related issues we have created a dedicated mailing list <oauth-security-repo...@ietf.org>. For implementation specific bugs we will attempt to forward the appropriate developers. Ciao Hannes & Derek
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
