Skip to main content

PCP Extension for Third Party Authorization
draft-wing-pcp-third-party-authz-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Dan Wing , Tirumaleswar Reddy.K , Prashanth Patil , Reinaldo Penno
Last updated 2013-05-24
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-wing-pcp-third-party-authz-00
PCP                                                              D. Wing
Internet-Draft                                                  T. Reddy
Intended status: Standards Track                                P. Patil
Expires: November 26, 2013                                      R. Penno
                                                                   Cisco
                                                            May 25, 2013

              PCP Extension for Third Party Authorization
                  draft-wing-pcp-third-party-authz-00

Abstract

   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.

   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.

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 http://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 November 26, 2013.

Copyright Notice

   Copyright (c) 2013 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents

Wing, et al.           Expires November 26, 2013                [Page 1]
Internet-Draft      PCP for 3rd party Authorization             May 2013

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Notational Conventions  . . . . . . . . . . . . . . . . . . .   3
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Solution Overview . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Obtaining Token Using OAuth . . . . . . . . . . . . . . . . .   6
     5.1.  Generating ACCESS_TOKEN option  . . . . . . . . . . . . .   9
     5.2.  PCP server processing ACCESS_TOKEN option . . . . . . . .   9
     5.3.  Processing the PCP response . . . . . . . . . . . . . . .  11
   6.  PCP Server and Proxy behavior . . . . . . . . . . . . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     10.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   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
   Section 3.

   This draft addresses the requirement "Third Party Authorization"
   explained in section 4 of [I-D.reddy-pcp-auth-req].

   This document proposes that a PCP [RFC6887] 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.

   Note: There is no relationship with the THIRD_PARTY option defined in
   [RFC6887], which serves a different purpose.

Wing, et al.           Expires November 26, 2013                [Page 2]
Internet-Draft      PCP for 3rd party Authorization             May 2013

2.  Notational Conventions

   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 [RFC2119].

   WebRTC Server: Web server which supports WebRTC.

3.  Problem Statement

   To protect networks using real-time communications, firewalls or
   session border controllers are typically deployed.  Firewalls usually
   include Application Layer Gateway functionality, which intercepts and
   analyzes the session signaling traffic such as the Session Initiation
   Protocol (SIP) [RFC3261] and creates dynamic mapping to permit the
   corresponding media traffic.  In particular, a firewall extracts
   media transport addresses, transport protocol and ports from the
   session description and creates a dynamic mapping for media to flow
   through.  This model has the following problems:

   1.  It does not work if the session signaling is end-to-end encrypted
       (say, using TLS).

   2.  It does not work if the firewall does not understand the session
       signaling protocol, or extensions to the protocol, used by the
       endpoints.

   3.  It does not work if the 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)

   When an enterprise deploys a WebRTC [I-D.ietf-rtcweb-overview] or SIP
   server, the above problems are relevant because:

   1.  The session signaling between the WebRTC application running in
       the browser and the web server will use TLS.

   2.  WebRTC does not enforce a particular session signaling protocol;
       therefore, the firewall is unlikely to understand the signaling
       protocol.

   3.  The session signaling and the peer-to-peer media may traverse
       different firewalls.

   As a result the firewall will block media traffic.

   A mitigation to the problems above is for the enterprise to deploy a
   TURN server on their DMZ, and have WebRTC clients use that TURN

Wing, et al.           Expires November 26, 2013                [Page 3]
Internet-Draft      PCP for 3rd party Authorization             May 2013

   server.  The use-case explained in Section 4.2.5.1 of
   [I-D.ietf-rtcweb-use-cases-and-requirements] refers to deploying a
   TURN [RFC5766] server to audit all media sessions from inside the
   company premises to any external peer.

   However, using TURN for all such communication causes some problems
   for the enterprise network administrator :

   o  Enterprise firewalls would typically have granular policies to
      permit call initiated using selected WebRTC servers (Dr.  Good) it
      trusts and block others (Dr.  Evil).

   o  TURN server is just providing the 5-tuple details (source IP
      address, destination IP address, protocol number, source port
      number, and destination port number) but no other details of the
      WebRTC or SIP server being used to establish the call.

   o  TURN server could increase media latency as explained in section
      4.1.2.2 of [RFC5245] and high-end TURN server would be needed (For
      example when TLS-over-TCP transport is used between the client and
      the server) to cater to all such calls.

   o  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 [RFC5766].  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 the 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.

   o  Some of the other limitations of TURN explained in section 2.6 of
      [RFC5766] are, the value of the Diffserv field may not be
      preserved, the Explicit Congestion Notification (ECN) field may be
      reset etc.

4.  Solution Overview

   In the below topology, the main functional elements involved are :

                  =========================
                  |  WebRTC Server        |
                  =========================
                            |  3rd Party Network
                            |

Wing, et al.           Expires November 26, 2013                [Page 4]
Internet-Draft      PCP for 3rd party Authorization             May 2013

                            |
                    ==================
                    |    WAN         |-----+-+----+---+----+-+---
                    ==================                 |
                              |                        |
                              |                        |
                              |                        |
                      +-------+-------+                |
                      | Firewall  -   |                |
                      | PCP Server    |                |
                      +-------+-------+                |
                              |                        |
                              |                        |
      Branch office           |                        | Mobile Network
   -+-+-----+-----------+-+-----+--------         ----+-+-------+------
                              |                        |
                           +-+------+                 +--------+
                           | Alice  |                 | Bob    |
                           +--------+                 +--------+

   Users : Alice, Bob

       Figure 1: WebRTC server in a different administrative domain

   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, firewall need to permit the ICE [RFC5245]
   connectivity checks and subsequent media traffic.

   In such a scenario the specification proposes the following technique
   to solve the problem :

   1.  The PCP client authenticates tests the PCP server by sending its
       first 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.

   2.  The PCP client then obtains a cryptographic token from an OAuth
       2.0 server.

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

Wing, et al.           Expires November 26, 2013                [Page 5]
Internet-Draft      PCP for 3rd party Authorization             May 2013

   4.  The PCP server uses the TOKEN_ACCESS option to perform third
       party authorization.

   This technique can also be used by a PCP capable NAT to permit MAP
   request from the PCP client so that the client can learn the External
   IP Addresses and Ports using MAP request/response.  If server
   reflexive candidates learnt using STUN [RFC5389] and External IP
   addresses/Ports learnt using PCP are different then the candidates
   learnt via PCP are encoded in the ICE offer and answer just like the
   server reflexive candidates.

   This technique can be used by any other Application Function trusted
   by the network to permit time-bound, encrypted, peer-to-peer traffic.

5.  Obtaining Token Using OAuth

   This section explains OAuth 2.0 authorization framework [RFC6749] to
   solve the "Third Party Authorization" requirement explained in
   section 4 of [I-D.reddy-pcp-auth-req].

   The following mapping of OAuth concepts to PCP is used :

              +----------------------+----------------------------+
              |         OAuth        |            PCP             |
              +======================+============================+
              | Client               | PCP Client                 |
              +----------------------+----------------------------+
              | Resource owner       | Authorization Server. For  |
              |                      | example the WebRTC server  |
              +----------------------+----------------------------+
              | Authorization server | Authorization server.      |
              +----------------------+----------------------------+
              | Resource server      | PCP Server                 |
              +----------------------+----------------------------+

           Figure 2: OAuth terminology mapped to PCP terminology

   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 PCP
   ACESS_TOKEN option to access the protected resources hosted by the
   resource server (PCP server).  The PCP server validates the token and

Wing, et al.           Expires November 26, 2013                [Page 6]
Internet-Draft      PCP for 3rd party Authorization             May 2013

   takes appropriate action e.g., allow the PCP request to create
   mappings on the PCP server.

                        +---------------+
                       ^|               +-------+
             +--------->| Authorization |       |
             |          | Server        |       |
             |          |               |       |  Authorization
             |          |               |<--+   | (e.g Permit MAP/PEER)
    (1)      |          +---------------+   |   |   (4)
    Access   |                              |   |
    Token    |                   Get Token  |   |
    Request  |                    Resource  |   |
             |                        (3)   |   |
             |                              |   |
             |                              |   V
     +-------+---+                       +-+----=-----+
     |           |         (2)           |            |
     |           | PCP Request + Access  |            |
     | PCP       | Token                 | PCP        |
     | Client    |---------------------->| Server     |
     |           |                       |            |
     |           |                       |            |
     +-----------+                       +------------+

                          Figure 3: Interactions

   OAuth in [RFC6749] defines four grant types.  This specification uses
   the OAuth grant type "Implicit" explained in section 1.3.2 of
   [RFC6749] where the PCP client is issued an access token directly.
   The scope of the access token explained in section 3.3 of [RFC6749]
   MUST be PCP.

       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                                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Wing, et al.           Expires November 26, 2013                [Page 7]
Internet-Draft      PCP for 3rd party Authorization             May 2013

      |                        key id                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | access token length           |    Reserved3                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    access token                               |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 4: PCP ACCESS_TOKEN Option

   The fields are described below:

   Option Length:  16 bits.  Indicates the length of the enclosed data,
      in octets.

   Domain Name Length:  Length of the 'Domain Name' field in octets.

   Server Domain Name:  The domain name of the Authorized Server that
      generated the access token.

   Timestamp:  64-bit unsigned integer field containing a timestamp.
      The value indicates the number of seconds 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).

   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 [RFC6749].

   key id  key id, which is an identifier generated by the authorization
      server.  It generates this key id by computing a hash over the
      access token using SHA-1 and truncating the hash to 96 bits
      (retaining the left most bits).

   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 [RFC6887]), length of the access token needs to be restricted
      to fit within the maximum PCP message size.  The access token is
      defined in section 1.4 of [RFC6749].  TBD : what is the
      recommended/maximum token length for PCP.  We need a discussion of
      this maximum length and analysis of what that means

   access token:  The access token issued by the authorization server.

Wing, et al.           Expires November 26, 2013                [Page 8]
Internet-Draft      PCP for 3rd party Authorization             May 2013

   Option Name:  ACCESS_TOKEN

   Number:  TBA in the mandatory-to-process range (IANA)

   Purpose:  This option conveys the token granted by authorization
      server for third party authorization.

   Valid for Opcodes:  MAP, PEER

   Length:  Variable, but MUST NOT be 0.

   May appear in :  request.  May appear in response only if it appeared
      in the associated request.

   Maximum occurrences :  1

5.1.  Generating ACCESS_TOKEN option

   The mechanism used by the 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 [RFC6819].  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.

5.2.  PCP server processing ACCESS_TOKEN option

   The PCP server performs processing in the order of the paragraphs
   below.

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

   When a PCP request with 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 :

   Lifetime + Delta > abs(RDnew - TSnew)

Wing, et al.           Expires November 26, 2013                [Page 9]
Internet-Draft      PCP for 3rd party Authorization             May 2013

   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_INVALID error response.

   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 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.

   If the token is invalid or the request exceeds what is authorized by
   the token then the PCP server generates AUTHORIZATION_INVALID 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.

   Handle token type was selected for the following reasons :

   1.  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.

   2.  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 PCP
       server can make sure that the token cannot be used for anything
       else.

   3.  If PCP authentication [I-D.ietf-pcp-authentication] 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.

   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

Wing, et al.           Expires November 26, 2013               [Page 10]
Internet-Draft      PCP for 3rd party Authorization             May 2013

   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 and requiring the
   authorization server generate its message integrity over exactly the
   PCP fields, in the same order, that will be sent by the PCP client.
   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 token, such as
   difficulties with revocation etc, are discussed in[RFC6819].

   Note to implementors : 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.

5.3.  Processing the PCP response

   Upon receiving a PCP response, the PCP client performs the normal
   processing described in Section 8.3 of [RFC6887].  If the PCP
   response was SUCCESS (0), the PCP server has determined that the
   token is valid.  If the PCP response was AUTHORIZATION_INVALID, it
   indicates that the token could be invalid, expired or the PCP request
   exceeded what is authorized by the token.

6.  PCP Server and Proxy behavior

   The ACCESS_TOKEN option is mandatory-to-process (its most significant
   bit is clear).  Thus, per existing behavior described in [RFC6887], 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.

   PCP Proxy MUST follow the rules mentioned in section of 7 of
   [I-D.ietf-pcp-proxy] when processing ACCESS_TOKEN option.

Wing, et al.           Expires November 26, 2013               [Page 11]
Internet-Draft      PCP for 3rd party Authorization             May 2013

7.  Security Considerations

   Security considerations discussed in [RFC6887] and PCP authentication
   [I-D.ietf-pcp-authentication] are to be taken into account.

   PCP server will delete explicit dynamic mappings after lifetime of
   the cryptographic token expires.  The PCP server could maintain the
   mapping for an extra Delta seconds.  The Delta value (e.g 10 seconds)
   would be locally configured on the PCP server.  PCP client must
   obtain a new cryptographic token from the authorization server when
   the current token becomes invalid or expires.  The PCP client must
   propagate the new cryptographic token to the PCP server to refresh
   the lifetime of the mappings before the current token becomes invalid
   or expires.  PCP server in addition to timestamp checking can also
   maintain a cache of used kid as an effective countermeasure against
   replay attacks.

8.  IANA Considerations

   We request IANA register the PCP option ACCESS_TOKEN and the result
   codes AUTHORIZATION_REQUIRED and AUTHORIZATION_INVALID in
   [pcp-registry].

9.  Acknowledgements

   Authors would like to thank Charles Eckel and Paul Jones for their
   comments and review.

10.  References

10.1.  Normative References

   [I-D.ietf-pcp-authentication]
              Wasserman, M., Hartman, S., and D. Zhang, "Port Control
              Protocol (PCP) Authentication Mechanism", draft-ietf-pcp-
              authentication-01 (work in progress), October 2012.

   [I-D.ietf-pcp-proxy]
              Boucadair, M., Penno, R., and D. Wing, "Port Control
              Protocol (PCP) Proxy Function", draft-ietf-pcp-proxy-02
              (work in progress), February 2013.

   [I-D.reddy-pcp-auth-req]
              Reddy, T., Patil, P., Wing, D., and R. Penno, "PCP
              Authentication Requirements", draft-reddy-pcp-auth-req-03
              (work in progress), May 2013.

Wing, et al.           Expires November 26, 2013               [Page 12]
Internet-Draft      PCP for 3rd party Authorization             May 2013

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

   [RFC6407]  Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
              of Interpretation", RFC 6407, October 2011.

   [RFC6749]  Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
              6749, October 2012.

   [RFC6887]  Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
              Selkirk, "Port Control Protocol (PCP)", RFC 6887, April
              2013.

   [pcp-registry]
              IANA, , "Port Control Protocol (PCP) Parameters", May
              2013, <http://www.iana.org/assignments/pcp-parameters/pcp-
              parameters.xml>.

10.2.  Informative References

   [I-D.ietf-rtcweb-overview]
              Alvestrand, H., "Overview: Real Time Protocols for Brower-
              based Applications", draft-ietf-rtcweb-overview-06 (work
              in progress), February 2013.

   [I-D.ietf-rtcweb-use-cases-and-requirements]
              Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
              Time Communication Use-cases and Requirements", draft-
              ietf-rtcweb-use-cases-and-requirements-10 (work in
              progress), December 2012.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245, April
              2010.

   [RFC5766]  Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
              Relays around NAT (TURN): Relay Extensions to Session
              Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.

Wing, et al.           Expires November 26, 2013               [Page 13]
Internet-Draft      PCP for 3rd party Authorization             May 2013

   [RFC6342]  Koodli, R., "Mobile Networks Considerations for IPv6
              Deployment", RFC 6342, August 2011.

   [RFC6819]  Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0
              Threat Model and Security Considerations", RFC 6819,
              January 2013.

Authors' Addresses

   Dan Wing
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, California  95134
   USA

   Email: dwing@cisco.com

   Tirumaleswar Reddy
   Cisco Systems, Inc.
   Cessna Business Park, Varthur Hobli
   Sarjapur Marathalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: tireddy@cisco.com

   Prashanth Patil
   Cisco Systems, Inc.
   Cessna Business Park, Varthur Hobli
   Sarjapur Marthalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: praspati@cisco.com

   Reinaldo Penno
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose  95134
   USA

   Email: repenno@cisco.com

Wing, et al.           Expires November 26, 2013               [Page 14]