| 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
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.
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 (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 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.
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.
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.
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:
When an enterprise deploys a WebRTC [I-D.ietf-rtcweb-overview] or SIP server, the above problems are relevant because:
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 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 :
In the below topology, the main functional elements involved are :
=========================
| WebRTC Server |
=========================
| 3rd Party Network
|
|
==================
| 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 :
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.
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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| access token length | Reserved3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| access token |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: PCP ACCESS_TOKEN Option
The fields are described below:
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.
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)
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 :
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 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.
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.
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.
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.
We request IANA register the PCP option ACCESS_TOKEN and the result codes AUTHORIZATION_REQUIRED and AUTHORIZATION_INVALID in [pcp-registry].
Authors would like to thank Charles Eckel and Paul Jones for their comments and review.