Internet DRAFT - draft-reddy-pcp-auth-req

draft-reddy-pcp-auth-req






PCP Working Group                                               T. Reddy
Internet-Draft                                                  P. Patil
Intended status: Standards Track                                 D. Wing
Expires: January 11, 2014                                       R. Penno
                                                                   Cisco
                                                           July 10, 2013


                    PCP Authentication Requirements
                      draft-reddy-pcp-auth-req-04

Abstract

   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.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 11, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as



Reddy, et al.           Expires January 11, 2014                [Page 1]

Internet-Draft            PCP Auth Requirements                July 2013


   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Third Party Authorization . . . . . . . . . . . . . . . . . . . 5
   5.  Other recommendations . . . . . . . . . . . . . . . . . . . . . 7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Appendix A.  Change History . . . . . . . . . . . . . . . . . . . . 8
     A.1.  Change from -01 to -02  . . . . . . . . . . . . . . . . . . 8
     A.2.  Change from -02 to -03  . . . . . . . . . . . . . . . . . . 8
     A.3.  Change from -03 to -04  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8































Reddy, et al.           Expires January 11, 2014                [Page 2]

Internet-Draft            PCP Auth Requirements                July 2013


1.  Introduction

   This document derives requirements for PCP Authentication from PCP
   deployment scenarios and scope described in [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.


2.  Terminology

   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 [RFC2119].

   This note uses terminologies defined in [RFC4949] such as realm,
   security association, identity, credential etc.


3.  Requirements

   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.

      *  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.

      *  The identity details of the client could be used for auditing.

   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.

   REQ-3:  A PCP server MUST be able to indicate that a request will not
      be processed without authentication.

   REQ-4:  If a PCP client authenticates with a PCP server,

      A.  The client MUST be able to verify the integrity and origin of
          responses from the server.



Reddy, et al.           Expires January 11, 2014                [Page 3]

Internet-Draft            PCP Auth Requirements                July 2013


      B.  The server MUST be able to send authenticated unsolicited
          responses.

      C.  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.

      D.  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.

   REQ-5:  It is important that PCP not leak privacy information between
      the PCP client and PCP server,

      A.  The authentication mechanism MUST be able to keep credentials
          hidden from eavesdroppers on path between the client and
          server.

      B.  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
          [RFC6887].  Other PCP drafts MUST evaluate if confidentiality
          is OPTIONAL for new PCP opcodes and options introduced.

      C.  PCP authentication SHOULD be immune to passive dictionary
          attacks.

      D.  PCP Authentication MUST ensure that an attacker snooping PCP
          messages cannot guess the SA.

   REQ-6:  To ease troubleshooting and ensure fate sharing, PCP
      authentication and PCP messages MUST be multiplexed over the same
      port.

   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.

   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.

   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:



Reddy, et al.           Expires January 11, 2014                [Page 4]

Internet-Draft            PCP Auth Requirements                July 2013


         +------------+                       |
         | PCP Client |-----+                 |
         +--(Host 1)--+     |   +-----------+ |     +----------+
                            +---|           | |     |          |
                                | PCP Proxy |-------|PCP Server|
                            +---|           | |     |          |
         +------------+     |   +-----------+ |     +----------+
         | PCP Client |-----+                 |
         +--(Host 2)--+               possible boundary
                                 <- Home side | ISP side ->

      A.  MUST be able to validate message integrity of PCP messages
          from the PCP server and client respectively.

      B.  MUST be able to ensure message integrity after updating the
          PCP message for cases described in sections 6 and 7 of
          [I-D.ietf-pcp-proxy].

      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.

   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 [BitTorrent], WebRTC[I-D.ietf-rtcweb-overview]/SIP
      [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.

   REQ-11:  It is RECOMMENDED to choose a widely deployed authentication
      technique with known security properties rather than inventing a
      new authentication mechanism.

   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.


4.  Third Party Authorization

   REQ-13: In addition to a two party authentication that has been
   discussed in this draft, a mechanism for third party authorization



Reddy, et al.           Expires January 11, 2014                [Page 5]

Internet-Draft            PCP Auth Requirements                July 2013


   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 Figure 1 , 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.


                  =========================
                  |  SIP Server        |
                  =========================
                            |  3rd Party Network
                            |
                            |
                    ==================
                    |    WAN         |-----+-+----+---+----+-+---
                    ==================                       |
                              |                              |
                              |                              |
                              |                              |
                      +-------+-------+                      |
                      | Firewall  -   |                      |
                      | PCP Server    |                      |
                      +-------+-------+                      |
                              |                              |
                              |                              |
      Network A               |                              | Network B
   -+-+-----+-----------+-+-----+--------         -----+-+-------+------
                              |                              |
                           +-+------+                 +--------+
                           | Alice  |                 | Bob    |
                           +--------+                 +--------+


   Users : Alice, Bob


       Figure 1: WebRTC server in a different administrative domain







Reddy, et al.           Expires January 11, 2014                [Page 6]

Internet-Draft            PCP Auth Requirements                July 2013


5.  Other recommendations

      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.


6.  IANA Considerations

   This document does not require any action from IANA.


7.  Security Considerations

   This entire document is about security considerations for PCP.


8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
              RFC 4949, August 2007.

   [RFC6887]  Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
              Selkirk, "Port Control Protocol (PCP)", RFC 6887,
              April 2013.

8.2.  Informative References

   [BitTorrent]
              "Cohen, B., "The BitTorrent Protocol Specification Version
              11031", February 2008.", September 2012.

   [I-D.ietf-pcp-proxy]
              Boucadair, M., Penno, R., and D. Wing, "Port Control
              Protocol (PCP) Proxy Function", draft-ietf-pcp-proxy-03
              (work in progress), June 2013.



Reddy, et al.           Expires January 11, 2014                [Page 7]

Internet-Draft            PCP Auth Requirements                July 2013


   [I-D.ietf-rtcweb-overview]
              Alvestrand, H., "Overview: Real Time Protocols for Brower-
              based Applications", draft-ietf-rtcweb-overview-06 (work
              in progress), February 2013.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.


Appendix A.  Change History

A.1.  Change from -01 to -02

   o  Requirements reorganized based on commonality

   o  New requirement 3(c(2)) added.

A.2.  Change from -02 to -03

   o  Merged REQ-1 and REQ-7

   o  Updated Section 5 "Other recommendations"

A.3.  Change from -03 to -04

   o  Updated REQ-4, REQ-9 and REQ-14.


Authors' Addresses

   Tirumaleswar Reddy
   Cisco Systems, Inc.
   Cessna Business Park, Varthur Hobli
   Sarjapur Marathalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: tireddy@cisco.com











Reddy, et al.           Expires January 11, 2014                [Page 8]

Internet-Draft            PCP Auth Requirements                July 2013


   Prashanth Patil
   Cisco Systems, Inc.
   Bangalore
   India

   Email: praspati@cisco.com


   Dan Wing
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, California  95134
   USA

   Email: dwing@cisco.com


   Reinaldo Penno
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, California  95134
   USA

   Email: repenno@cisco.com



























Reddy, et al.           Expires January 11, 2014                [Page 9]