<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-wing-pcp-third-party-authz-03"
     ipr="trust200902">
  <front>
    <title abbrev="PCP for 3rd party Authorization ">PCP Extension for Third
    Party Authorization</title>

    <author fullname="Dan Wing" initials="D." surname="Wing">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>170 West Tasman Drive</street>

          <city>San Jose</city>

          <region>California</region>

          <code>95134</code>

          <country>USA</country>
        </postal>

        <email>dwing@cisco.com</email>
      </address>
    </author>

    <author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>Cessna Business Park, Varthur Hobli</street>

          <street>Sarjapur Marathalli Outer Ring Road</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560103</code>

          <country>India</country>
        </postal>

        <email>tireddy@cisco.com</email>
      </address>
    </author>

    <author fullname="Prashanth Patil" initials="P." surname="Patil">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street></street>

          <street></street>

          <city>Bangalore</city>

          <country>India</country>
        </postal>

        <email>praspati@cisco.com</email>
      </address>
    </author>

    <author fullname="Reinaldo Penno" initials="R." surname="Penno">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>170 West Tasman Drive</street>

          <city>San Jose</city>

          <region></region>

          <code>95134</code>

          <country>USA</country>
        </postal>

        <phone></phone>

        <email>repenno@cisco.com</email>

        <uri></uri>
      </address>
    </author>

    <date />

    <workgroup>PCP</workgroup>

    <abstract>
      <t>It is often desirable for an application server to permit a flow
      across a firewall, as happens today when a firewall includes an
      Application Layer Gateway (ALG) function. However, an ALG has several
      weaknesses.</t>

      <t>This document describes a cryptographic technique for an application
      server to permit a flow across a firewall. This technique uses OAuth and
      a new PCP option.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>It is desirable for a third party to permit flows across a firewall.
      A typical use-case is a SIP proxy (which is aware of legitimate calls)
      which is not co-located with a firewall. Today, this functionality is
      provided by a firewall implementing a SIP-aware Application Layer
      Gateway function, which examines the SIP signaling to that SIP proxy and
      opens the appropriate pinholes for the RTP media. This has
      disadvantages, as described in detail in section <xref
      target="prob"></xref>.</t>

      <t>This document addresses requirement "Third Party Authorization"
      explained in section 4 of <xref
      target="I-D.reddy-pcp-auth-req"></xref>.</t>

      <t>This document proposes that a <xref target="RFC6887">PCP</xref>
      client communicate with an OAuth Authorization Server to obtain a
      cryptographic token for its media flow. That token is included in the
      PCP request and validated by the PCP server.</t>

      <t>Note: There is no relationship with the THIRD_PARTY option defined in
      <xref target="RFC6887"></xref>, which serves a different purpose.
      THIRD_PARTY Option for MAP and PEER Opcodes described in <xref
      target="RFC6887"></xref> is only applicable when all entities i.e the
      PCP client, PCP server and Application Server, are deployed within the
      same administrative domain. Since PCP server does not listen on a public
      interface, an Application Server outside the site will not be able to
      use THIRD_PARTY option to request services on behalf of the client.</t>
    </section>

    <section anchor="notation" title="Notational Conventions">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119"></xref>.</t>

      <!--
      <t>This document uses terminology defined in <xref
      target="RFC6887"></xref> and <xref
      target="RFC5245"></xref>.</t>
-->

      <t>WebRTC Server: A web server that supports WebRTC <xref
      target="I-D.ietf-rtcweb-overview"></xref>.</t>
    </section>

    <section anchor="prob" title="Problem Statement">
      <t>To protect networks using real-time communications, firewalls or
      session border controllers <xref target="RFC5853"></xref> are typically
      deployed. Firewalls usually implement Application Layer Gateway
      functionality, which intercepts and analyzes session signaling traffic
      such as Session Initiation Protocol (SIP) <xref target="RFC3261"></xref>
      messages and creates a dynamic mapping to permit the corresponding media
      traffic. In particular, a firewall extracts media transport addresses,
      transport protocol and ports from session description and creates a
      dynamic mapping for media to flow through. This model will not work in
      the following cases: <list style="numbers">
          <t>Session signaling is end-to-end encrypted (say, using TLS).</t>

          <t>Firewall does not understand the session signaling protocol, or
          extensions to the protocol, used by the endpoints.</t>

          <t>Session signaling and media traverse different firewalls (e.g.,
          signaling exits a network via one firewall whereas media exits a
          network via a different firewall)</t>
        </list></t>

      <t>When an enterprise deploys WebRTC, the above problems are relevant
      because: <list style="numbers">
          <t>Session signaling between WebRTC application running in a browser
          and a web server will use TLS.</t>

          <t>WebRTC does not enforce a particular session signaling protocol;
          therefore, a firewall is unlikely to understand the signaling
          protocol.</t>

          <t>Session signaling and peer-to-peer media may traverse different
          firewalls.</t>
        </list></t>

      <t>As a result firewalls block media traffic.</t>

      <!--

<t>There are some ways to mitigate such a block:</t>

      <t>One mitigation is to use a Session Border Controller,
      which is anactive participants with call signaling. Like firewalls,
      they also create dynamic mappings to permit media traffic. This
      forces call signaling and media through specific IP addresses,
      belonging to the SBC or an SBC-controlled media relay device.
  However, there is no way to get a SBC to become on path with a
WebRTC session.</t>

-->

      <t>A mitigation to the problems above is for an enterprise to deploy a
      TURN server in the DMZ and have WebRTC clients use the TURN server. <!--
TURN is also used as an alternative to permit media traffic,
      i.e. use TCP transport between the client and TURN server
      because firewalls could be configured to block UDP entirely. -->The
      use-case explained in Section 4.2.5.1 of <xref
      target="I-D.ietf-rtcweb-use-cases-and-requirements"></xref> refers to
      deploying a TURN <xref target="RFC5766"></xref> server to audit all
      media sessions from inside the company premises to any external
      peer.</t>

      <t>However, using TURN for all such communication causes some problems
      for an enterprise network administrator : <list style="symbols">
          <t>Enterprise firewalls would typically have granular policies to
          permit calls initiated using selected WebRTC servers (Dr. Good) it
          trusts and block the rest (Dr. Evil).</t>

          <t>A TURN server just provides a 5-tuple (source IP address,
          destination IP address, protocol number, source port number, and
          destination port number) for auditing and no other details of the
          WebRTC or SIP server being used to establish the call.</t>

          <t>A TURN server could increase media latency as explained in
          section 4.1.2.2 of <xref target="RFC5245"></xref>.</t>

          <t>A TURN server could either be located in the DMZ of the
          enterprise network or located in the public Internet. If the TURN
          server is located in the public Internet it comes at a high cost to
          the provider of the TURN server, since the server typically needs a
          high-bandwidth connection to the Internet as explained in the
          Introduction of <xref target="RFC5766"></xref>. As a consequence, it
          is best to use a TURN server only when a direct communication path
          cannot be found. When the client and a peer use ICE to determine
          communication path, ICE will use hole punching techniques to search
          for a direct path first and only use a TURN server when a direct
          path cannot be found.</t>

          <t>Other limitations of TURN are explained in section 2.6 of <xref
          target="RFC5766"></xref>. For example the value of Diffserv field
          may not be preserved, Explicit Congestion Notification (ECN) field
          may be reset etc.</t>
        </list></t>
    </section>

    <section anchor="problem_stmt" title="Solution Overview">
      <t>In the below topology, the main functional elements involved are
      :</t>

      <?rfc needLines="30" ?>

      <figure anchor="Figure1"
              title="WebRTC server in a different administrative domain">
        <artwork align="left"><![CDATA[               
               =========================
               |  WebRTC Server        |
               =========================
                         |  3rd Party Network
                         |  
                         | 
                 ==================
                 |    WAN         |-----+-+----+---+----+-+---
                 ==================                 |
                           |                        |
                           |                        |  
                           |                        | 
                   +-------+-------+                |  
                   | Firewall  -   |                |
                   | PCP Server    |                | 
                   +-------+-------+                | 
                           |                        |
                           |                        |
   Branch office           |                        | Mobile Network
-+-+-----+-----------+-+-----+--------         ----+-+-------+------
                           |                        |
                        +-+----------+           +--------+
                        | Alice  -   |           | Bob    |
                        | PCP Client |           |        | 
                        +------------+           +--------+  


Users : Alice, Bob
WebRTC Server : OAuth 2.0 Authorization server
 
]]></artwork>
      </figure>

      <t>In the topology, a WebRTC Server is deployed in a third party network
      trusted by the Enterprise. For the two endpoints to successfully
      establish media sessions, a firewall needs to permit ICE <xref
      target="RFC5245"></xref> connectivity checks and subsequent media
      traffic.</t>

      <t>In such a scenario this specification proposes that a PCP client
      follows the steps described below: <list style="numbers">
          <t>The PCP client makes a PCP request without any authorization. If
          the PCP server returns an AUTHORIZATION_REQUIRED error message, the
          PCP client concludes that the PCP server is mandating the use of
          third party authorization.</t>

          <t>The PCP client then obtains a cryptographic token from an OAuth
          2.0 Authorization server.</t>

          <t>The PCP client sends a PCP request including the cryptographic
          token in the TOKEN_ACCESS option, defined below. Alternatively, the
          PCP client could first obtain a cryptographic token from the OAuth
          2.0 Authorization server and send the PCP request with the
          TOKEN_ACCESS option by default.</t>

          <t>The PCP server uses the TOKEN_ACCESS option to perform third
          party authorization.</t>
        </list></t>

      <t>The technique proposed in the specification can be used by any other
      Application Function trusted by the network to permit time-bound,
      encrypted, peer-to-peer traffic.</t>
    </section>

    <section anchor="oauth" title="Obtaining a Token Using OAuth">
      <t>This section explains OAuth 2.0 authorization framework <xref
      target="RFC6749"></xref> to solve the "Third Party Authorization"
      requirement explained in section 4 of <xref
      target="I-D.reddy-pcp-auth-req"></xref>.</t>

      <figure anchor="oauth_pcp_terminology_map"
              title="OAuth terminology mapped to PCP terminology">
        <preamble>The following mapping of OAuth concepts to PCP is used
        :</preamble>

        <artwork align="left"><![CDATA[
              +----------------------+----------------------------+
              |         OAuth        |            PCP             |
              +======================+============================+
              | Client               | PCP Client                 |
              +----------------------+----------------------------+
              | Resource owner       | Authorization Server. For  |
              |                      | example the WebRTC server  |
              +----------------------+----------------------------+
              | Authorization server | Authorization server.      |
              +----------------------+----------------------------+
              | Resource server      | PCP Server                 |
              +----------------------+----------------------------+
              ]]></artwork>
      </figure>

      <t></t>

      <t>Using the OAuth 2.0 authorization framework, a PCP client
      (third-party application) obtains limited access to a PCP server
      (resource server) on behalf of the WebRTC server (resource owner or
      authorization server). The PCP client requests access to resources
      controlled by the resource owner (WebRTC server) and hosted by the
      resource server (PCP server). The PCP client obtains an access token,
      lifetime, and other access attributes like the PCP options and opcodes
      that the PCP client is permitted to use from the authorization server.
      The PCP client conveys the token in the PCP ACESS_TOKEN option to access
      the protected resources hosted by the resource server (PCP server). The
      PCP server validates the token and takes appropriate action e.g., allows
      the PCP request to create mappings on the PCP server.</t>

      <figure anchor="interactions" title="Interactions">
        <artwork align="left"><![CDATA[                        +---------------+
        +-------------->|               +-------+
        |               | Authorization |       |
        |      +--------| Server        |       |    
        |      |        |(WebRTC Server)|       |  Authorization 
        |      |        |               |<--+   | (e.g Permit MAP/PEER)
  (1)   |      |        +---------------+   |   |   (5)
 Access |      |  Access                    |   |
 Token  |      |  Token          Get Token  |   |  
 Request|      |   (2)            Resource  |   | 
        |      |                    (4)     |   |
        |      |                            |   |   
        |      V                            |   V   
     +-------+---+                       +-+----=-----+
     |           |         (3)           |            |
     |           | PCP Request + Access  |            |
     | PCP       | Token                 | PCP        |
     | Client    |---------------------->| Server     |
     | (Alice)   | PCP Response (6)      | (Firewall) |
     |           |<----------------------|            |
     +-----------+                       +------------+

User : Alice

]]></artwork>
      </figure>

      <t></t>

      <t>OAuth in <xref target="RFC6749"></xref> defines four grant types.
      This specification uses the OAuth grant type "Implicit" explained in
      section 1.3.2 of <xref target="RFC6749"></xref> where the PCP client is
      issued an access token directly. The scope of the access token explained
      in section 3.3 of <xref target="RFC6749"></xref> MUST be PCP.</t>

      <section title="ACCESS_TOKEN Option">
        <t>This specification defines a new PCP ACCESS_TOKEN Option that is
        described in<xref target="Figure6"></xref>.</t>

        <figure anchor="Figure6" title="PCP ACCESS_TOKEN Option">
          <artwork align="left"><![CDATA[
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Option Code=TBD|  Reserved     |   Option Length               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Domain Name Length            |    Reserved1                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                                                               | 
      |                    Domain Name                                |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Timestamp                                  |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Lifetime                                   |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        key id                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | access token length           |    Reserved3                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |                    access token                               |  
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     
]]></artwork>
        </figure>

        <t>The fields are described below: <list style="hanging">
            <t hangText="Option Length:">16 bits. Indicates the length of the
            enclosed data, in octets. Variable, but MUST NOT be 0.</t>

            <t hangText="Domain Name Length:">Length of the 'Domain Name'
            field in octets.</t>

            <t hangText="Reserved1:">set to 0 by sender and ignored by the
            receiver.</t>

            <t hangText="Server Domain Name:">The domain name of the
            Authorized Server that generated the access token.</t>

            <t hangText="Timestamp:">64-bit unsigned integer field containing
            a timestamp. The value indicates the time since January 1, 1970,
            00:00 UTC, by using a fixed point format. In this format, the
            integer number of seconds is contained in the first 48 bits of the
            field, and the remaining 16 bits indicate the number of 1/64K
            fractions of a second (Native format - Unix).</t>

            <t hangText="Lifetime:">The lifetime of the access token since the
            response was generated, in seconds. For example, the value 3600
            indicates one hour. The Lifetime value SHOULD be equal to the
            "expires_in" parameter defined in section 4.2.2 of <xref
            target="RFC6749"></xref>.</t>

            <t hangText="key id:">An ephemeral and unique key identifier
            generated by the authorization server. The authorization server
            MUST NOT generate the same key identifier twice within the
            lifetime of the access token.</t>

            <t hangText="access token length:">Length of the access token
            field in octets. OAuth does not impose any limitation on the
            length of the access token but since PCP messages cannot exceed
            1100 octets (Section 7 of <xref target="RFC6887"></xref>), access
            token length needs to be restricted to fit within the maximum PCP
            message size. The access token is defined in section 1.4 of <xref
            target="RFC6749"></xref>. TBD : what is the recommended/maximum
            token length for PCP. We need a discussion of this maximum length
            and analysis of what that means</t>

            <t hangText="Reserved3:">set to 0 by sender and ignored by the
            receiver.</t>

            <t hangText="access token:">The access token issued by the
            authorization server.</t>

            <t hangText="Option Name:">ACCESS_TOKEN</t>

            <t hangText="Number:">TBA in the mandatory-to-process range
            (IANA)</t>

            <t hangText="Purpose:">This option conveys the token granted by
            the authorization server for third party authorization.</t>

            <t hangText="Valid for Opcodes:">MAP, PEER</t>

            <t hangText="May appear in :">request.</t>

            <t hangText="Maximum occurrences :">1</t>
          </list></t>
      </section>

      <section title="Generating the ACCESS_TOKEN option">
        <t>The mechanism used by an OAuth client to obtain a token from the
        OAuth authorization server is outside the scope of this document. The
        OAuth client could obtain the token via in-band signaling or an
        exclusive out-of-band protocol. This specification uses the token type
        Handle described in <xref target="RFC6819"></xref>. A handle token is
        a reference to some internal data structure within the OAuth
        authorization server; the internal data structure contains the
        attributes of the token such as allowed PCP Opcode or PCP Option, etc.
        The PCP client, after receiving the access token from the OAuth
        authorization server, generates the ACCESS_TOKEN option which is
        included in the PCP request to the PCP server.</t>
      </section>

      <section title="PCP server processing ACCESS_TOKEN option">
        <t>A PCP server performs processing in the order described below.</t>

        <t>When a PCP server receives a PCP request with an ACCESS_TOKEN
        option, it will verify that the access token is valid. To address
        replay attacks, the PCP server MUST perform the following check :</t>

        <t>When a PCP request with an ACCESS_TOKEN Option is received, the
        received timestamp (TSnew in the Timestamp field) is checked and the
        cryptographic token is accepted if the timestamp is recent enough to
        the reception time of the PCP request, RDnew :</t>

        <t>Lifetime + Delta &gt; abs(RDnew - TSnew)</t>

        <t>The RECOMMENDED value for the allowed Delta is 5 seconds. If the
        timestamp is NOT within the boundaries then discard the PCP request
        with AUTHORIZATION-FAILED error response defined in <xref
        target="I-D.ietf-pcp-authentication"></xref>.</t>

        <t>After the validation described above, the PCP server communicates
        with the authorization server in order to validate the token and
        obtain token-bound data. The mechanism for communication is outside
        the scope of this document. The PCP server makes a request to the
        authorization server to validate the token but produces no other data
        with the request. If the token is successfully validated, the
        authorization server just returns the token bound authorization data
        in the response. The PCP server then matches this authorization data
        with what is requested in the PCP request sent by the PCP client. If
        the authorization sets match, the PCP server honors the PCP request
        made by the PCP client.</t>

        <t>If the token is invalid or the request exceeds what is authorized
        by the token then the PCP server generates an AUTHORIZATION-FAILED
        error response. An example might be that an OAuth authorization server
        permits creating 5 mappings, and the PCP request made by the client is
        trying to create a 6th mapping.</t>

        <t>Handle token type was selected for the following reasons :<list
            style="numbers">
            <t>The Authorization Server can inform the PCP server to revoke
            the access token after the call is terminated. This mechanism
            ensures that even if the PCP client does not close the dynamic
            mapping created, the PCP server based on the revocation
            notification from the Authorization Server can close the dynamic
            mapping.</t>

            <t>A PCP-controlled Firewall with restrictive policies may also
            want to validate with the Authorization Server if the selected
            candidate pairs in the final offer/answer match the 5-tuple {dest
            addr, source addr, protocol, dest port, source port} sessions
            traversing the Firewall. This validation ensures that the PCP
            client is using the token only to send and receive the media
            streams finalized in the call to the remote peer. Thus the PCP
            server can make sure that the token cannot be used for anything
            else.</t>

            <t>If PCP authentication <xref
            target="I-D.ietf-pcp-authentication"></xref> is used then the PCP
            server may also validate with the authorization server if the
            access token is issued and used by the same user or not.</t>
          </list></t>

        <t>Another approach, not discussed in this document, is a
        self-contained token where all the information necessary to
        authenticate the validity of the token is contained within the token
        itself. This approach has the benefit of avoiding a protocol between
        the PCP server and the OAuth authentication server for token
        validation, thus reducing latency. However, this approach has the
        drawback of needing a large PCP packet to accommodate the token.
        Because PCP messages are limited to 1100 octets, using the handle
        approach is more flexible and the trade-off for additional latency is
        reasonable. The other disadvantages of self-contained tokens, such as
        difficulties with revocation etc., are discussed in<xref
        target="RFC6819"> </xref>.</t>
      </section>

      <section title="Processing the PCP response">
        <t>Upon receiving a PCP response, the PCP client performs the normal
        processing described in Section 8.3 of <xref target="RFC6887"></xref>.
        If the PCP response was SUCCESS (0), the PCP server has determined
        that the token is valid. If the PCP response was AUTHORIZATION-FAILED,
        it indicates that the token could be invalid, expired or the PCP
        request exceeded what is authorized by the token.</t>
      </section>
    </section>

    <section anchor="proxy" title="PCP Server and Proxy behavior">
      <t>The ACCESS_TOKEN option is mandatory-to-process (its most significant
      bit is clear). Thus, per existing behavior described in <xref
      target="RFC6887"></xref>, a PCP server receiving this option MUST return
      the error MALFORMED_OPTION if the option contents are malformed, or
      UNSUPP_OPTION if the option is unrecognized, unimplemented, or disabled,
      or if the client is not authorized to use the option.</t>

      <t>A PCP Proxy MUST follow the rules mentioned in section of 3.4 of
      <xref target="I-D.ietf-pcp-proxy"></xref> when processing the
      ACCESS_TOKEN option.</t>
    </section>

    <section anchor="auth" title="Usage with PCP Authentication mechanism">
      <t>The following steps MUST be followed when PCP third party
      authorization is used with PCP authentication mechanism.</t>

      <t><list style="symbols">
          <t>PCP client MUST send the access token after successful EAP
          authentication. This provides integrity protection for ACCESS_TOKEN
          option.</t>

          <t>If PCP Auth session lifetime expires before the authorization
          token expires and the PCP client, PCP server fail to trigger
          re-authentication then dynamic mappings created because of third
          party authorization MUST be deleted.</t>
        </list></t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>Security considerations discussed in <xref target="RFC6887"></xref>
      and PCP authentication <xref
      target="I-D.ietf-pcp-authentication"></xref> are to be taken into
      account. If left unprotected the Authorization server could present a
      means for an attacker to poll a series of possible token values, fishing
      for a valid token. Therefore, the Authorization Server SHOULD issue
      special credentials to PCP server to access it and the communication
      between PCP server and Authorization server MUST be protected using
      TLS.</t>

      <t>A PCP server will delete explicit dynamic mappings after the lifetime
      of the cryptographic token expires. The PCP client must obtain a new
      cryptographic token from the authorization server before the current
      token becomes invalid or expires. The PCP client must propagate the new
      cryptographic token to the PCP server to refresh lifetime of mappings
      before the current token becomes invalid or expires. The PCP server in
      addition to timestamp checking can also maintain a cache of used key id
      as an effective countermeasure against replay attacks.</t>

      <t>Discussion: If the additional latency needs to be avoided and it is
      permissible to create a PCP mapping briefly for PCP clients, an
      implementation could create PCP mappings while the token is being
      validated. The PCP server could create a mapping immediately, send a PCP
      response and in parallel start verification of the token. If the
      verification request times out or returns a failure response, the PCP
      mapping can be destroyed and a PCP mapping update is sent to the PCP
      client. The PCP server while waiting for the validation response to
      arrive from Authorization server can either drop or buffer the traffic
      matching the mapping created.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>We request IANA register the PCP option ACCESS_TOKEN and the result
      code AUTHORIZATION_REQUIRED in <xref target="pcp-registry"></xref>.</t>
    </section>

    <section anchor="ack" title="Acknowledgements">
      <t>Authors would like to thank Dave Thaler, Charles Eckel, Paul Jones,
      Dacheng Zhang, Anca Zamfir, Parthasarathi R and Suresh kumar for their
      comments and review.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include='reference.RFC.6887'?>

      <?rfc include='reference.I-D.ietf-pcp-proxy'?>

      <?rfc include='reference.I-D.reddy-pcp-auth-req'?>

      <?rfc include='reference.I-D.ietf-pcp-authentication'?>

      <?rfc include="reference.RFC.5389"?>

      <?rfc include="reference.RFC.6407"?>

      <?rfc include="reference.RFC.6749"?>

      <reference anchor="pcp-registry"
                 target="http://www.iana.org/assignments/pcp-parameters/pcp-parameters.xml">
        <front>
          <title>Port Control Protocol (PCP) Parameters</title>

          <author fullname="IANA" surname="IANA">
            <organization></organization>
          </author>

          <date month="May" year="2013" />
        </front>
      </reference>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.ietf-rtcweb-use-cases-and-requirements'
?>

      <?rfc include='reference.I-D.ietf-rtcweb-overview'?>

      <?rfc include="reference.RFC.6342"?>

      <?rfc include="reference.RFC.5853"?>

      <?rfc include="reference.RFC.5766"?>

      <?rfc include="reference.RFC.5245"?>

      <?rfc include="reference.RFC.3261"?>

      <?rfc include="reference.RFC.6819"?>

      <!---->
    </references>
  </back>
</rfc>
