One document matched: draft-reddy-pcp-auth-req-01.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-01" 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:">PCP allows a server to send multiple responses.
To properly support that model with authentication, a client that
sends an authenticated request MUST be able to verify the integrity
and origin of an subsequent unsolicited response should it choose to
do so.</t>
<t hangText="REQ-4:">PCP allows a server to send multiple responses.
If the original request/response exchange was authenticated, a
server MUST be able to send a subsequent authenticated unsolicited
Response.</t>
<t hangText="REQ-5:">PCP allows a server to send multiple responses.
If the server wants to send an unsolicited message, but the previous
security association has expired, the server MUST be able to trigger
re-authentication with the client.</t>
<t hangText="REQ-6:">Clients that have authenticated with the server
MUST verify the integrity of the contents of all unsolicited
responses.</t>
<t hangText="REQ-7:">If there are circumstances where PCP responses
do not include integrity related to a current security association,
then those messages MUST NOT be trusted without soliciting an
integrity protected version.</t>
<t hangText="REQ-8:">It is important that PCP not leak privacy
information between the PCP client and the PCP server(s). Thus, the
PCP authentication MUST NOT exchange the PCP clients authentication
credentials in clear text. For example, exchanging the PCP username
in clear text would violate this requirement.</t>
<t hangText="REQ-9:">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 hangText="REQ-10:">The authentication mechanism SHOULD be immune
to passive dictionary attacks.</t>
<t hangText="REQ-11:">PCP Authentication MUST ensure that an
attacker snopping the PCP messages cannot guess the SA.</t>
<t hangText="REQ-12:">To ease troubleshooting and ensure fate
sharing, the PCP authentication and PCP messages MUST be multiplexed
over the same port.</t>
<t hangText="REQ-13:">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-14:">PCP client MUST be able to ascertain that it
is talking to the right PCP server, especially when PCP server is
located in a different administrative domain.</t>
<t hangText="REQ-15:">For the scenarios described in REQ-13, PCP
authentication mechanism MUST be functional across address and port
translation, including NAPT64 and NAPT44.</t>
<t hangText="REQ-16:">If a PCP client and server desire
authentication then a PCP proxy, that modifies PCP request/response
before forwarding messages, MUST validate message integrity of PCP
messages from the PCP server and client respectively. <figure>
<artwork><![CDATA[
+------------+ |
| PCP Client |-----+ |
+--(Host 1)--+ | +-----------+ | +----------+
+---| | | | |
| PCP Proxy |-------|PCP Server|
+---| | | | |
+------------+ | +-----------+ | +----------+
| PCP Client |-----+ |
+--(Host 2)--+ possible boundary
<- Home side | ISP side ->]]></artwork>
</figure></t>
<t hangText="REQ-17:">PCP Proxy must also 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>
<t hangText="REQ-18:">PCP authentication SHOULD support a mechanism
where only one PCP client on the host will authenticate with the PCP
server and any other PCP clients SHOULD 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.</t>
<t hangText="REQ-19:">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-20:">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>Upon receiving a challenge with a certain REALM, if the PCP
client does not have credentials for that REALM, it SHOULD attempt
to use the username GUEST and password GUEST. The GUEST 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 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 (REQ-14).</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>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:20:26 |