One document matched: draft-reddy-pcp-auth-req-04.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-reddy-pcp-auth-req-04" ipr="trust200902">
<front>
<title abbrev="PCP Auth Requirements">PCP Authentication
Requirements</title>
<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/>
<city>Bangalore</city>
<country>India</country>
</postal>
<email>praspati@cisco.com</email>
</address>
</author>
<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="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>California</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>repenno@cisco.com</email>
</address>
</author>
<date/>
<workgroup>PCP Working Group</workgroup>
<abstract>
<t>In an attempt to reach consensus on a PCP authentication mechanism,
this document describes requirements for PCP authentication. It is hoped
this can serve as the basis for a comparison of PCP authentication
mechanisms.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>This document derives requirements for PCP Authentication from PCP
deployment scenarios and scope described in <xref target="RFC6887"/> and
other PCP drafts. The document focuses on requirements and does not make
a suggestion on the authentication mechanism to be used to satisfy
requirements.</t>
</section>
<section title="Terminology">
<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"/>.</t>
<t>This note uses terminologies defined in <xref target="RFC4949"/> such
as realm, security association, identity, credential etc.</t>
</section>
<section title="Requirements">
<t><list style="hanging">
<t hangText="REQ-1:">PCP MUST provide client authentication. PCP
client and server MUST also be able to mutually authenticate. Mutual
authentication is especially necessary when the PCP server is
located in a different administrative domain from the PCP client.
Credentials to gain access to the network could be different from
the credentials used to authenticate with the PCP server. <list
style="symbols">
<t>The identity details of the client could be used by the PCP
server to grant access to certain PCP opcodes or PCP options.
For example GUESTS might not be permitted to use the MAP opcode
and only ADMINISTRATOR might be permitted to use the THIRD_PARTY
option.</t>
<t>The identity details of the client could be used for
auditing.</t>
</list></t>
<t hangText="REQ-2:">PCP Authentication MUST generate security
association for integrity protection of PCP request and response.
This and all subsequent requirements are not applicable to multicast
PCP responses like ANNOUNCE.</t>
<t hangText="REQ-3:">A PCP server MUST be able to indicate that a
request will not be processed without authentication.</t>
<t hangText="REQ-4:">If a PCP client authenticates with a PCP
server,<list style="letters">
<t>The client MUST be able to verify the integrity and origin of
responses from the server.</t>
<t>The server MUST be able to send authenticated unsolicited
responses.</t>
<t>If a PCP response does not include integrity related to a
current security association, then those messages MUST NOT be
trusted without soliciting an integrity protected version.</t>
<t>The server MUST be able to trigger reauthentication with the
client. The unsolicited message for authentication trigger MUST
be integrity protected if there is a valid unexpired SA.</t>
</list></t>
<t hangText="REQ-5:">It is important that PCP not leak privacy
information between the PCP client and PCP server,<list
style="letters">
<t>The authentication mechanism MUST be able to keep credentials
hidden from eavesdroppers on path between the client and
server.</t>
<t>Confidentiality of the PCP messages is OPTIONAL for PCP
request and response of opcodes MAP, PEER, ANNOUNCE and options
THIRD_PARTY, PREFER_FAILURE and FILTER as explained in <xref
target="RFC6887"/>. Other PCP drafts MUST evaluate if
confidentiality is OPTIONAL for new PCP opcodes and options
introduced.</t>
<t>PCP authentication SHOULD be immune to passive dictionary
attacks.</t>
<t>PCP Authentication MUST ensure that an attacker snooping PCP
messages cannot guess the SA.</t>
</list></t>
<t hangText="REQ-6:">To ease troubleshooting and ensure fate
sharing, PCP authentication and PCP messages MUST be multiplexed
over the same port.</t>
<t hangText="REQ-7:">PCP authentication MUST accommodate
authentication between administrative domains. For example, a PCP
client may wish to communicate directly to an ISP’s PCP
server, even though the in-home CPE router does not support PCP. In
this scenario the PCP client needs to directly authenticate with the
ISP’s PCP server.</t>
<t hangText="REQ-8:">For the scenarios described in REQ-7, the PCP
authentication mechanism MUST be functional across address and port
translation, including NAPT64 and NAPT44.</t>
<t hangText="REQ-9:">A PCP proxy that modifies PCP messages SHOULD
have the ability to independently authenticate with the PCP client
and PCP server. The presence of a PCP proxy hence requires two
separately authenticates SAs. As a consequence, the PCP
proxy:<figure>
<artwork><![CDATA[
+------------+ |
| PCP Client |-----+ |
+--(Host 1)--+ | +-----------+ | +----------+
+---| | | | |
| PCP Proxy |-------|PCP Server|
+---| | | | |
+------------+ | +-----------+ | +----------+
| PCP Client |-----+ |
+--(Host 2)--+ possible boundary
<- Home side | ISP side ->
]]></artwork>
</figure><list style="letters">
<t>MUST be able to validate message integrity of PCP messages
from the PCP server and client respectively.</t>
<t>MUST be able to ensure message integrity after updating the
PCP message for cases described in sections 6 and 7 of <xref
target="I-D.ietf-pcp-proxy"/>.</t>
</list>The PCP proxy MUST also permit authentication on only one
side of the proxy. For example, a customer premises host may not
authenticate with the PCP proxy but the PCP proxy may authenticate
with the PCP server. </t>
<t hangText="REQ-10:">It is RECOMMENDED that PCP authentication
support a mechanism where authentication on one port MUST be usable
on other ports without requiring another authentication exchange for
other ports. For example, there could multiple applications on the
host like BitTorrent <xref target="BitTorrent"/>, WebRTC<xref
target="I-D.ietf-rtcweb-overview"> </xref>/SIP <xref
target="RFC3261"/> using PCP. Multiple authentication exchanges
increase load on the PCP server and chatter on the network. For
example, if 'N' messages are to be exchanged for PCP authentication
and 'M' independent applications implement their own PCP client, a
total of N*M messages have to be exchanged and 'M' number of SAs
maintained for each host.</t>
<t hangText="REQ-11:">It is RECOMMENDED to choose a widely deployed
authentication technique with known security properties rather than
inventing a new authentication mechanism.</t>
<t hangText="REQ-12:">Changes in PCP to accommodate authentication
SHOULD be minimal so that updates and additions to the
authentication mechanism have minimal bearing on modifying PCP.</t>
</list></t>
</section>
<section title="Third Party Authorization">
<t>REQ-13: In addition to a two party authentication that has been
discussed in this draft, a mechanism for third party authorization MUST
also be supported. This is applicable in cases where a third party
authorizes the use of a resource on a PCP server for a desired PCP
client. For example, as depicted in <xref target="Figure1"/> , a PCP
request to a PCP capable firewall authorized by a SIP proxy rather than
by virtue of the end user making the PCP request. The PCP server is to
permit a PCP MAP request from the PCP client if the user is making a SIP
call with the Enterprise or a trusted SIP server in 3rd party network,
otherwise do not allow MAP request from that particular user. In this
scenario the first party is the user, second party is the PCP server
(which is also the firewall) and the third party is the SIP server,
where the user is authorized to use MAP request only when making a call
using the trusted SIP Server.</t>
<t><figure anchor="Figure1"
title="WebRTC server in a different administrative domain">
<artwork align="left"><![CDATA[
=========================
| SIP Server |
=========================
| 3rd Party Network
|
|
==================
| WAN |-----+-+----+---+----+-+---
================== |
| |
| |
| |
+-------+-------+ |
| Firewall - | |
| PCP Server | |
+-------+-------+ |
| |
| |
Network A | | Network B
-+-+-----+-----------+-+-----+-------- -----+-+-------+------
| |
+-+------+ +--------+
| Alice | | Bob |
+--------+ +--------+
Users : Alice, Bob
]]></artwork>
</figure></t>
</section>
<section title="Other recommendations">
<t><list style="empty">
<t>REQ-14: There SHOULD be support for a means to provide integrity
protection without user authentication, i.e., an anonymous client
should be able to verify a PCP server using server-side-only auth
and as a consequence obtain an SA which will be used for PCP message
integrity. For example, a client visiting foreign networks such as a
hotel, hot spot etc where the client may gain access to the network
but does not know the credentials to authenticate with the PCP
server. The negotiation of SA should be secure such that the SA is
only known to the anonymous client and PCP server.</t>
</list></t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document does not require any action from IANA.</t>
</section>
<section title="Security Considerations">
<t>This entire document is about security considerations for PCP.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"
?>
<?rfc include="reference.RFC.4949"
include="reference.RFC.6887"?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.ietf-pcp-proxy'
?>
<?rfc include='reference.I-D.ietf-rtcweb-overview'
?>
<?rfc include="reference.RFC.3261"?>
<reference anchor="BitTorrent" target="">
<front>
<title>Cohen, B., "The BitTorrent Protocol Specification Version
11031", February 2008.</title>
<author fullname="" surname="">
<organization/>
</author>
<date day="0" month="September" year="2012"/>
</front>
</reference>
<!---->
</references>
<section title="Change History">
<t/>
<section title="Change from -01 to -02">
<t><list style="symbols">
<t>Requirements reorganized based on commonality</t>
<t>New requirement 3(c(2)) added.</t>
</list></t>
</section>
<section title="Change from -02 to -03">
<t><list style="symbols">
<t>Merged REQ-1 and REQ-7</t>
<t>Updated Section 5 "Other recommendations"</t>
</list></t>
</section>
<section title="Change from -03 to -04">
<t><list style="symbols">
<t>Updated REQ-4, REQ-9 and REQ-14.</t>
</list></t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:38:05 |