One document matched: draft-wing-pcp-third-party-authz-00.xml
<?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-00"
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>Cessna Business Park, Varthur Hobli</street>
<street>Sarjapur Marthalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<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 draft addresses the 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.</t>
<!--
<t>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 Authorization server, are deployed
within the same administrative domain. Since PCP server does not listen
on a public interface, an Authorization Server outside the site will not
be able to use THIRD_PARTY option to request services from a PCP
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: Web server which supports WebRTC.</t>
</section>
<section anchor="prob" title="Problem Statement">
<t>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) <xref target="RFC3261"></xref> 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: <list
style="numbers">
<t>It does not work if the session signaling is end-to-end encrypted
(say, using TLS).</t>
<t>It does not work if the firewall does not understand the session
signaling protocol, or extensions to the protocol, used by the
endpoints.</t>
<t>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)</t>
</list></t>
<t>When an enterprise deploys a WebRTC <xref
target="I-D.ietf-rtcweb-overview"></xref> or SIP server, the above
problems are relevant because: <list style="numbers">
<t>The session signaling between the WebRTC application running in
the browser and the web server will use TLS.</t>
<t>WebRTC does not enforce a particular session signaling protocol;
therefore, the firewall is unlikely to understand the signaling
protocol.</t>
<t>The session signaling and the peer-to-peer media may traverse
different firewalls.</t>
</list></t>
<t>As a result the firewall will 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 the enterprise to deploy a
TURN server on their DMZ, and have WebRTC clients use that 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 the enterprise network administrator : <list style="symbols">
<t>Enterprise firewalls would typically have granular policies to
permit call initiated using selected WebRTC servers (Dr. Good) it
trusts and block others (Dr. Evil).</t>
<t>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.</t>
<t>TURN server could increase media latency as explained in section
4.1.2.2 of <xref target="RFC5245"></xref> 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.</t>
<t>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 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.</t>
<t>Some of the other limitations of TURN explained in section 2.6 of
<xref target="RFC5766"></xref> are, the value of the Diffserv field
may not be preserved, the 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 |
+--------+ +--------+
Users : Alice, Bob
]]></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, firewall need to permit the ICE <xref
target="RFC5245"></xref> connectivity checks and subsequent media
traffic.</t>
<t>In such a scenario the specification proposes the following technique
to solve the problem : <list style="numbers">
<t>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.</t>
<t>The PCP client then obtains a cryptographic token from an OAuth
2.0 server.</t>
<t>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.</t>
<t>The PCP server uses the TOKEN_ACCESS option to perform third
party authorization.</t>
</list></t>
<t>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 <xref target="RFC5389"></xref> 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.</t>
<t>This technique 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 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 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.</t>
<figure anchor="interactions" title="Interactions">
<artwork align="left"><![CDATA[ +---------------+
^| +-------+
+--------->| 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 |
| | | |
| | | |
+-----------+ +------------+]]></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>
<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.</t>
<t hangText="Domain Name Length:">Length of the 'Domain Name' field
in octets.</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 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).</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">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).</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>), 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 <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="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
authorization server for third party authorization.</t>
<t hangText="Valid for Opcodes:">MAP, PEER</t>
<t hangText="Length:">Variable, but MUST NOT be 0.</t>
<t hangText="May appear in :">request. May appear in response only
if it appeared in the associated request.</t>
<t hangText="Maximum occurrences :">1</t>
</list></t>
<section title="Generating ACCESS_TOKEN option">
<t>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 <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>The PCP server performs processing in the order of the paragraphs
below.</t>
<t>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
:</t>
<t>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 :</t>
<t>Lifetime + Delta > 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_INVALID error response.</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 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 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.</t>
<t>Handle token type was selected for the following reasons :<list
style="numbers">
<t>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>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.</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 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<xref
target="RFC6819"> </xref>.</t>
<t>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.</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_INVALID, 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>PCP Proxy MUST follow the rules mentioned in section of 7 of <xref
target="I-D.ietf-pcp-proxy"></xref> when processing ACCESS_TOKEN
option.</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.</t>
<t>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.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>We request IANA register the PCP option ACCESS_TOKEN and the result
codes AUTHORIZATION_REQUIRED and AUTHORIZATION_INVALID in <xref
target="pcp-registry"></xref>.</t>
</section>
<section anchor="ack" title="Acknowledgements">
<t>Authors would like to thank Charles Eckel and Paul Jones 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.5766"?>
<?rfc include="reference.RFC.5245"?>
<?rfc include="reference.RFC.3261"?>
<?rfc include="reference.RFC.6819"?>
<!---->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:23:47 |