uma-claims-sec.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN"
"http://xml.resource.org/authoring/rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC6749 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6749.xml">
<!ENTITY RFC7159 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7159.xml">
]>
<rfc category="std" docName="draft-uma-claims-sec-ext" id="kantara"
     ipr="kantara" target="draft" version="1.0">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc='yes' ?>

  <?rfc tocdepth='4' ?>

  <?rfc symrefs='yes' ?>

  <?rfc sortrefs='yes' ?>

  <?rfc compact='yes' ?>

  <?rfc subcompact='no' ?>

  <front>
    <title abbrev="uma-claims-sec-ext">UMA Claims-Gathering Extension for
    Enhanced Security</title>

    <author fullname="Maciej Machulak" initials="M." role="editor"
            surname="Machulak">
      <organization>Synergetics</organization>

      <address>
        <email>maciej@synergetics.be</email>
      </address>
    </author>

    <author fullname="Eve Maler" initials="E." surname="Maler">
      <organization>ForgeRock</organization>

      <address>
        <email>eve.maler@forgerock.com</email>
      </address>
    </author>

    <author fullname="Justin Richer" initials="J." surname="Richer">
      <organization>Bespoke Engineering</organization>

      <address>
        <email>kantara@justin.richer.org</email>
      </address>
    </author>

    <date day="29" month="March" year="2016" />

    <abstract>
      <t>This extension to UMA enhances security by providing an alternate
      requesting party claims endpoint that alters the claims-gathering
      process to avoid a session fixation attack.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>This extension to the User-Managed Access (UMA) protocol provides
      enhanced security by defining an alternate requesting party claims
      endpoint, called the security-enhanced claims endpoint. This endpoint
      alters the claims-gathering process to generate an unpredictable return
      URI by returning a new UMA permission ticket value, thereby avoiding an
      existing session fixation attack. This extension applies to UMA V1.0
      <xref target="UMA10" />, UMA V1.0.1 <xref target="UMA101" />, and any
      version of UMA susceptible to the attack.</t>

      <section title="Notational Conventions">
        <t>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
        <xref target="RFC2119" />.</t>

        <t>Unless otherwise noted, all protocol properties and values are case
        sensitive. JSON <xref target="RFC7159" /> data structures defined by
        this specification MAY contain extension properties that are not
        defined in this specification. Any entity receiving or retrieving a
        JSON data structure SHOULD ignore extension properties it is unable to
        understand. Names of such extension properties that are unprotected
        from collisions are outside the scope of this specification.</t>
      </section>

      <section anchor="summary"
               title="Extension Summary and Configuration Data">
        <t>Following is a summary of this extension and how its identifying
        URI is used.<list style="symbols">
            <t>Identifying URI: <spanx
            style="verb">https://docs.kantarainitiative.org/uma/extensions/claims-sec-1.0</spanx><list
                style="symbols">
                <t>An UMA authorization server implementing this specification
                MUST provide this identifying URI in the <spanx
                style="verb">uma_profiles_supported</spanx> property in its
                configuration data.</t>
              </list></t>

            <t>Extension author and contact information: Maciej Machulak
            (maciej@synergetics.be).</t>

            <t>Updates or obsoletes: None; this extension is new.</t>

            <t>Security considerations: The purpose of the extension is to
            enhance security.</t>

            <t>Privacy considerations: None additional.</t>

            <t>Error states: None additional.</t>
          </list></t>
      </section>
    </section>

    <section anchor="getting-authz-accessing-resource"
             title="Security Extension">
      <t>See <xref target="UMAsession" /> for background information on this
      attack, the provided mitigation, and further discussion.</t>

      <section anchor="purpose"
               title="Purpose and Applicability of the Extension">
        <t>One of the methods of requesting party trust elevation defined by
        UMA is redirecting an end-user requesting party to the authorization
        server for claims-gathering. Since the return URI from this
        claims-gathering process is predictable, this method is susceptible to
        a session fixation attack. As a consequence, a malicious requesting
        party may be able to access a protected resource not intended for
        access by that party by having a legitimate user supply claims and
        associate them with the attacker's permission ticket.</t>

        <t>This extension mitigates the attack by enhancing the security of
        the claims-gathering mechanism to return an unpredictable URI, thereby
        making an attacker unable to guess the return state from the victim's
        claims-gathering process and halting the attack. The URI is made
        unguessable by returning a new permission ticket value which the
        client then uses to interact with the authorization server from that
        point forward, discarding any previous ticket values in the process.
        This functionality is implemented through a new security-enhanced
        claims endpoint that replaces the requesting party claims endpoint;
        the rest of the claims-gathering process remains unchanged.</t>

        <t>Any authorization server intending to use interactive
        claims-gathering as a means of trust elevation SHOULD implement the
        extension defined in this specification. Trust elevation through
        authentication context (requesting party authentication at the
        authorization endpoint) and pushed claims (claims provided to the RPT
        endpoint by the client) are not susceptible to this attack.</t>
      </section>

      <section anchor="attack" title="Attack Sequence">
        <t>Preconditions:<list style="symbols">
            <t>The attacker (a malicious requesting party) and the victim (a
            legitimate end-user requesting party) both use a client (same
            instance or different instances) with the same client ID.</t>

            <t>The client(s) are legitimate and uncompromised.</t>

            <t>Both the attacker and the victim already have their respective
            AATs which are valid.</t>
          </list></t>

        <t>Sequence:<list style="numbers">
            <t>The attacker attempts access to an UMA protected resource
            normally available to the victim but not the attacker.</t>

            <t>The resource server registers a requested permission; the
            authorization server returns a permission ticket; and the resource
            server returns a permission ticket (along with other data) to the
            client.</t>

            <t>The client asks for authorization data and RPT at the
            authorization server; the authorization server returns a <spanx
            style="verb">need_info</spanx> response with an <spanx
            style="verb">error_details</spanx> block containing a <spanx
            style="verb">redirect_user</spanx> hint (or the client infers the
            requirement to redirect the browser to the requesting party claims
            endpoint).</t>

            <t>The client attempts to redirect the attacker's browser to the
            requesting party claims endpoint, but the attacker copies the
            redirect URL (optionally stripping off the state parameter),
            including a permission ticket query parameter, and passes it to
            the victim. The attacker may try to prevent the redirect from
            their client as well.</t>

            <t>The victim is tricked to access the URL provided by the
            attacker (e.g. using a phishing technique). After being phished
            with the URL, the victim assists the authorization server in
            completing the claims-gathering process.</t>

            <t>The authorization server redirects the victim back to the
            client. No relevant session is found in the client, so the
            post-redirect request fails. Alternatively, if the attacker
            controls the victim's network access, they prevent communication
            between victim and client and stop the redirect.</t>

            <t>After sufficient time has elapsed, the attacker sends a final
            request for an RPT using their original ticket value and receives
            an RPT with sufficient authorization data to access the UMA
            protected resource.</t>

            <t>The attacker gains access to the UMA protected resource using
            the RPT empowered with the victim's claims provided in (5).</t>
          </list></t>
      </section>

      <section anchor="mitigation" title="Mitigation of the Attack">
        <t>To mitigate this attack, an UMA authorization server indicating its
        conformance to this extension through the identifying URI defined in
        <xref target="summary" /> and the client conforming to this extension
        MUST do the following.<list style="symbols">
            <t>The authorization server MUST select a new unguessable value
            for the permission ticket and invalidate the permission ticket
            previously received from the client every time it adds a <spanx
            style="verb">ticket</spanx> query parameter to the <spanx
            style="verb">claims_redirect_uri</spanx> after a claims-gathering
            flow at this security-enhanced endpoint. This extension supersedes
            the <xref target="UMA101" /> Section 3.2.2 requirement "Permission
            tickets MUST NOT be single-use" and the Section 3.6.3 phrase "The
            same permission ticket value that the client provided in the
            request...". Consequently, the ticket becomes a single-use nonce
            in both its front-channel and back-channel correlation roles. This
            ticket value rotation defeats the attacker's ability to compose a
            successful RPT request in step 7 of the attack described in <xref
            target="attack" />.</t>

            <t>The client MUST read the new <spanx style="verb">ticket</spanx>
            value from the callback to its <spanx
            style="verb">claims_redirect_uri</spanx> and MUST discard the
            previous <spanx style="verb">ticket</spanx> value used in the
            request to the claims-gathering endpoint.</t>

            <t>The client MUST use new <spanx style="verb">ticket</spanx>
            value for all future interactions with the authorization server,
            including the RPT endpoint and security enhanced claims-gathering
            endpoint, until such time that its value is replaced again (such
            as by repeated calls to the security enhanced claims-gathering
            endpoint).</t>

            <t>The client SHOULD use the <spanx style="verb">state</spanx>
            parameter to prevent other forms of attacks against its <spanx
            style="verb">claims_redirect_uri</spanx> endpoint, but use of the
            <spanx style="verb">state</spanx> parameter alone does not prevent
            the attack described in this specification.</t>

            <t>The authorization server MUST provide a configuration data
            property for an alternate requesting party claims endpoint in its
            configuration data called <spanx
            style="verb">security_enhanced_claims_endpoint</spanx>, with the
            URI for the endpoint as its value.</t>

            <t>The authorization server MUST replace any use of the originally
            specified requesting party claims endpoint with the
            security-enhanced requesting party claims endpoint for interacting
            with the end-user requesting party to gather claims. The
            authorization server MUST NOT provide a configuration data
            property for the <spanx
            style="verb">requesting_party_claims_endpoint</spanx>
            configuration data. Effectively, this extension supersedes the
            <xref target="UMA10" /> and <xref target="UMA101" /> Section 1.4
            statement "If this property is absent, the authorization server
            does not interact with the end-user requesting party for claims
            gathering."</t>
          </list></t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no requests of IANA.</t>
    </section>

    <section anchor="Acknowledgments" title="Acknowledgments">
      <t>The following people made significant contributions to the Work
      Group's understanding of the attack (in alphabetical order):<list
          style="symbols">
          <t>Josh Mandel</t>

          <t>Sarah Squire</t>
        </list></t>
    </section>

    <section title="Security Considerations">
      <t>It is essential for an authorization server to handle only one style
      of claims gathering for clients. An authorization server must not allow
      clients to use both the requesting party claims endpoint and the
      security-enhanced claims endpoint to be used simultaneously, since it is
      impossible for the authorization server to differentiate between a
      legitimate request from a non-upgraded client (using a fixed permission
      ticket value) from a compromised client using the new protocol (and
      simply ignoring the new ticket value).</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <reference anchor="UMA10"
                 target="https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0.html">
        <front>
          <title>User-Managed Access (UMA) Profile of OAuth 2.0, Version
          1.0</title>

          <author initials="T." surname="Hardjono">
            <organization>MIT</organization>
          </author>

          <date day="04" month="April" year="2015" />
        </front>
      </reference>

      <reference anchor="UMA101"
                 target="https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0_1.html">
        <front>
          <title>User-Managed Access (UMA) Profile of OAuth 2.0, Version
          1.0.1</title>

          <author initials="T." surname="Hardjono">
            <organization>MIT</organization>
          </author>

          <date day="28" month="December" year="2015" />
        </front>
      </reference>

      &RFC2119;

      &RFC7159;
    </references>

    <references title="Informative References">
      <reference anchor="UMAsession"
                 target="http://kantarainitiative.org/confluence/display/uma/Understanding+the+Session+Fixation+Attack+on+UMA+Claims-Gathering+and+the+Provided+Mitigation">
        <front>
          <title>Understanding the Session Fixation Attack on UMA
          Claims-Gathering and the Provided Mitigation</title>

          <author initials="E." surname="Maler">
            <organization>ForgeRock</organization>
          </author>

          <date day="28" month="March" year="2016" />
        </front>
      </reference>
    </references>
  </back>
</rfc>