<?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&rsquo;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&rsquo;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>
