[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Web Authorization Protocol                                       D. Fett
Internet-Draft                                                   yes.com
Intended status: Standards Track                              J. Bradley
Expires: January 24, 2020                                         Yubico
                                                           July 23, 2019


   OAuth 2.0 Integrity Verification for Authorization Requests (IVAR)
                        draft-fett-oauth-ivar-00

Abstract

   This document describes a mechanism for the integrity protection of
   OAuth 2.0 authorization requests.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 24, 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





Fett & Bradley          Expires January 24, 2020                [Page 1]


Internet-Draft                 oauth-ivar                      July 2019


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions and Terminology . . . . . . . . . . . . . . .   3
   2.  Concept . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Client Metadata for IVAR  . . . . . . . . . . . . . . . . . .   3
   4.  Protocol  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Storing the Authorization Request . . . . . . . . . . . .   4
     4.2.  IVAR Verification . . . . . . . . . . . . . . . . . . . .   4
   5.  Fallback if JavaScript is unavailable . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Appendix A.  Document History . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   A number of attacks on OAuth 2.0 are based on the fact that the
   contents of the OAuth authorization request lack integrity and
   authenticity protection.  To launch an attack, an attacker might, for
   example, start an OAuth flow in his browser, use the authorization
   request URI created by the client, and send it to its victim (with or
   without manipulations).  The victim might then complete the
   authorization.  Since the attacker knows or has manipulated parts of
   the authorization request URI, certain security mechanisms in OAuth
   might then not work as expected --- undermining the security of OAuth
   or protocols based on OAuth, like OpenID Connect.

   Among others, the following attacks are facilitated by the lack of
   integrity and authenticity of the authorization request:

   o  Attacks on the redirection URI, in which an attacker manipulates
      the redirection URI and let it point either to a server controlled
      by the attacker or an endpoint at the client which discloses
      contents of the authorization response to the attacker.

   o  The PKCE Chosen Challenge Attack, described in [arXiv.1901.11520],
      wherein an attacker uses his access to the authorization response
      (see attacker model A3 in [I-D.ietf-oauth-security-topics]) to
      gain access to the user's resources.

   o  A variant of the AS Mix-Up attack in which a malicious AS
      redirects the user to an honest AS, re-using request parameters.
      (See [arXiv.1601.01229] for details.)




Fett & Bradley          Expires January 24, 2020                [Page 2]


Internet-Draft                 oauth-ivar                      July 2019


   While TLS protects the integrity of the authorization request, these
   attacks leverage the fact that an attacker can make a victim's
   browser visit arbitrary URIs, including those manipulated by the
   attacker or obtained by the attacker from one of his own interactions
   with the client.

   This document describes IVAR, a mechanism for the verification of the
   integrity and origin of the contents of the authorization request.

1.1.  Conventions and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   This specification uses the terms "access token", "refresh token",
   "authorization server", "resource server", "authorization endpoint",
   "authorization request", "authorization response", "token endpoint",
   "grant type", "access token request", "access token response", and
   "client" defined by The OAuth 2.0 Authorization Framework [RFC6749].

2.  Concept

   On a high level, IVAR works as follows: When the client starts a new
   OAuth authorization flow, it stores the whole authorization URI (or a
   hash thereof) in the web storage of the resource owner's browser
   under the client's origin.  When the AS received the authorization
   request, it opens an iframe from a URI the client registered with the
   AS beforehand.  To this "checking" iframe, the AS sends a cross-
   document message (postMessage) containing the whole authorization
   request URI as received by the AS.  If the URI matches the one stored
   by the client earlier, the client responds with a message "ok".  If
   not, the AS aborts the transaction.

3.  Client Metadata for IVAR

   Clients that support IVAR register the following metadata parameter
   in the OAuth 2.0 Dynamic Client Registration Protocol [RFC7591]:

   "ivar_uri".  The content MUST be an https URI from which the checking
   iframe is loaded by the AS.








Fett & Bradley          Expires January 24, 2020                [Page 3]


Internet-Draft                 oauth-ivar                      July 2019


4.  Protocol

   The steps of the IVAR protocol are defined in the following.

4.1.  Storing the Authorization Request

   Before the client redirects the resource owner's browser to the
   authorization server, the client stores information about the full
   redirection URI (including query parameters) in the web storage
   [WebStorage] of the resource owner's browser.  It is at the client's
   discretion to store either the full URI or a hash value of the URI.

   The data MUST be stored such that it is only accessible to the
   client's origin.  Its contents MUST NOT be modifiable or readable by
   any other origin.

   Since multiple OAuth flows may happen in the same browser at the same
   time, the storage mechanism MUST be able to store multiple entries in
   parallel.

4.2.  IVAR Verification

   After receiving the authorization request, the AS opens the client's
   "ivar_uri" in an iframe in its web site.  (The client is identified
   using the "client_id" parameter.)  The IVAR iframe script from the
   client sends a postMessage with the content "ready" to its parent
   iframe.

   The AS then sends a postMessage containing the full authorization
   request URI to the iframe.  It is important that the AS limits the
   intended receiver of this message to the origin of the "ivar_uri" to
   avoid leaking contents of the authorization request URI to an
   attacker.

   The client's script in the iframe then checks if an exact match of
   the authorization request URI sent by the AS can be found in the list
   of stored authorization request URIs.  If so, it checks that the
   postMessage containing the URI was received from the origin of the
   authorization request URI.  It then sends the string "ok" in a
   postMessage to its parent window.  It is again important that the
   intended receiver of this postMessage is set to the authorization
   request's origin.

   The AS ensures that the string "ok" is received in a postMessage
   originating from the IVAR iframe and the correct origin (from the
   "ivar_uri").  Only then it continues with the authorization flow.





Fett & Bradley          Expires January 24, 2020                [Page 4]


Internet-Draft                 oauth-ivar                      July 2019


   If any of these steps fail, the AS MUST abort the authorization flow
   and redirect the browser back to the client with an error value of
   "ivar_fail".

5.  Fallback if JavaScript is unavailable

   If the resource owner's browser does not support JavaScript, or
   JavaScript is disabled, the client cannot store the redirection URI.
   Likewise, the AS cannot run its part of the IVAR protocol.  The AS
   may skip the IVAR checks if, and only if, it detects that the
   resource owner's browser does not have JavaScript enabled (which is
   required for IVAR).  The respective check for JavaScript support MUST
   NOT be open to influence by an attacker.

   An attacker cannot usually disable JavaScript in a user's browser for
   an origin other than his own.  The attacker might, however, trick the
   uesr's browser into treating the IVAR checking script on the AS's
   origin as part of a cross-site scripting attack and thus disabling
   the affected JavaScript.  To achieve this, the attacker can add the
   text representation of the respective JavaScript in a (new) URI
   parameter.  Some browser's cross-site scripting auditing engines
   string match URI parameters inputs with contents in the source code
   of the web page.  If a match is found, the respective JavaScript is
   disabled.

   To avoid disabling of the IVAR checking script by an attacker, AS
   MUST disable browser-based detection of cross-site scripting using
   the non-standardized header "X-XSS-Protection: 0" or by sufficiently
   randomizing the source code of the IVAR checking script.

6.  Security Considerations

7.  IANA Considerations

8.  References

8.1.  Normative References

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/info/rfc6749>.

   [RFC7591]  Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
              P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
              RFC 7591, DOI 10.17487/RFC7591, July 2015,
              <https://www.rfc-editor.org/info/rfc7591>.





Fett & Bradley          Expires January 24, 2020                [Page 5]


Internet-Draft                 oauth-ivar                      July 2019


8.2.  Informative References

   [arXiv.1601.01229]
              Fett, D., Kuesters, R., and G. Schmitz, "A Comprehensive
              Formal Security Analysis of OAuth 2.0", January 2016,
              <http://arxiv.org/abs/1601.01229/>.

   [arXiv.1901.11520]
              Fett, D., Hosseyni, P., and R. Kuesters, "An Extensive
              Formal Security Analysis of the OpenID Financial-grade
              API", January 2019, <http://arxiv.org/abs/1901.11520/>.

   [I-D.ietf-oauth-security-topics]
              Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,
              "OAuth 2.0 Security Best Current Practice", draft-ietf-
              oauth-security-topics-13 (work in progress), July 2019.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [WebStorage]
              Hickson, I., "Web Storage (Second Edition) - W3C
              Recommendation 19 April 2016", Apr 2016,
              <https://www.w3.org/TR/webstorage/>.

Appendix A.  Document History

   [[ To be removed from the final specification ]]

   -00

   o  first draft

Authors' Addresses

   Daniel Fett
   yes.com

   Email: mail@danielfett.de






Fett & Bradley          Expires January 24, 2020                [Page 6]


Internet-Draft                 oauth-ivar                      July 2019


   John Bradley
   Yubico

   Email: ve7jtb@ve7jtb.com















































Fett & Bradley          Expires January 24, 2020                [Page 7]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/