PCP Authentication
RequirementsCisco Systems, Inc.Cessna Business Park, Varthur HobliSarjapur Marathalli Outer Ring RoadBangaloreKarnataka560103Indiatireddy@cisco.comCisco Systems, Inc.BangaloreIndiapraspati@cisco.comCisco Systems, Inc.170 West Tasman DriveSan JoseCalifornia95134USAdwing@cisco.comCisco Systems, Inc.170 West Tasman DriveSan JoseCalifornia95134USArepenno@cisco.comPCP Working GroupIn 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.This document derives requirements for PCP Authentication from PCP
deployment scenarios and scope described in PCP-base 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.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 .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. 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.The identity details of the client could be used for
auditing.PCP Authentication MUST also generate message
authentication key for integrity protection of PCP request and
response.PCP Servers MUST be able to indicate that a
request will not be processed without authentication.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.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.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.Clients that have authenticated with the server
MUST verify the integrity of the contents of all unsolicited
responses.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.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.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 PCP-base. Other PCP drafts MUST
evaluate if confidentiality is OPTIONAL or not for new PCP opcodes
and options introduced.The authentication mechanism SHOULD be immune
to passive dictionary attacks.PCP Authentication MUST ensure that an
attacker snopping the PCP messages cannot guess the SA.To ease troubleshooting and ensure fate
sharing, the PCP authentication and PCP messages MUST be multiplexed
over the same port.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.For the scenarios described in REQ-13, PCP
authentication mechanism MUST be functional across address and port
translation, including NAPT64 and NAPT44.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. PCP Proxy must also ensure message integrity
after updating the PCP message for cases described in sections 6 and
7 of .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 , WebRTC/SIP using PCP.All else equal, it is RECOMMENDED to choose a
widely deployed authentication technique with known security
properties rather than inventing a new authentication mechanism.Changes in PCP to accommodate authentication
SHOULD be minimal so that updates and additions to the
authentication mechanism have no bearing on modifying PCP.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).This document does not require any action from IANA.This document does not define an architecture nor a protocol; as such
it does not raise any security concerns.Cohen, B., "The BitTorrent Protocol Specification Version
11031", February 2008.