One document matched: draft-reddy-pcp-auth-req-02.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-02" 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="I-D.ietf-pcp-base">PCP-base</xref> 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>
</section>
<section title="Requirements">
<t><list style="hanging">
<t hangText="REQ-1:">PCP client and server MUST provide client
authentication. The client could be a host running a PCP client or
middle box (e.g., NAT) running a PCP Proxy. <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 would not be permitted to use MAP opcode,
ADMINISTRATOR is only permitted to use THIRD_PARTY option.</t>
<t>The identity details of the client could be used for
auditing.</t>
</list>PCP Authentication MUST also generate message
authentication key for integrity protection of PCP request and
response.</t>
<t hangText="REQ-2:">PCP Servers MUST be able to indicate that a
request will not be processed without authentication.</t>
<t hangText="REQ-3:">If the original PCP request/response was
authenticated,<list style="letters">
<t>A client MUST be able to verify the integrity and origin of a
subsequent response from the server.</t>
<t>A server MUST be able to send subsequent authenticated
unsolicited responses.</t>
<t>If a server wants to send an unsolicited message, but the
previous security association has expired<list style="numbers">
<t>The server can continue to use the same SA to protect
messages pertaining to that mapping, even if the SA is
technically expired.<list style="symbols">
<t>Such server notifications will not change state in
the PCP client.</t>
<t>The notification could be a trigger for the client to
re-authenticate. For example, if the server indicates
that external IP address/port has changed, the PCP
client can then re-authenticate with the server to
confirm if the external IP address/port for the mapping
has indeed changed.</t>
</list></t>
<t>The server can optionally trigger re-authentication with
the client.</t>
</list></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>
</list></t>
<t hangText="REQ-4:">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 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 explained in <xref
target="I-D.ietf-pcp-base">PCP-base</xref>. Other PCP drafts
MUST evaluate if confidentiality is OPTIONAL or not 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-5:">To ease troubleshooting and ensure fate
sharing, PCP authentication and PCP messages MUST be multiplexed
over the same port.</t>
<t hangText="REQ-6:">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-7:">PCP client and server MUST be able mutually
authenticate, especially 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.</t>
<t hangText="REQ-8:">For the scenarios described in REQ-6, 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 request/response
before forwarding messages, <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 validate message integrity of PCP messages from the PCP
server and client respectively.</t>
<t>MUST 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></t>
<t hangText="REQ-10:">It is RECOMMENDED that PCP authentication
support a mechanism where only one PCP client on the host
authenticates with the PCP server and other PCP clients be able to
reuse the previously negotiated key for integrity protection. For
example, 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:">All else equal, 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 no bearing on modifying PCP.</t>
</list></t>
</section>
<section title="Third Party Authorization">
<t>In addition to two party authentication that has been discussed in
this draft, a mechanism for third party authorization must also be
supported. This is required in cases where a third party authorizes the
use of a resource on a PCP server for a desired PCP client. For example,
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 if a user is making a SIP call with the
Enterprise SIP server, 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>
</section>
<section title="Other recommendations">
<t><list style="symbols">
<t>It is recommended that there be support for a means to provide
integrity protection without user authentication. For example, upon
receiving a challenge with a certain REALM, if the PCP client does
not have credentials for that REALM, the client will attempt to use
a default username and password. Default credentials are expected to
be configured on infrastructure where PCP authentication is not
necessary, but such guest users are given some (minimal)
authorization to use PCP. This addresses the problem when the client
is visiting foreign networks like a hotel, hot spot etc where it may
gain access to the network but does not know the credentials to
authenticate to the ISP’s PCP server when the in-home CPE
router does not support PCP and the PCP client needs to directly
authenticate with the ISP’s 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 document does not define an architecture nor a protocol; as such
it does not raise any security concerns.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.I-D.ietf-pcp-base'?>
<?rfc ?>
</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>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:21:29 |