[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 01 02 03 04

PCP Working Group                                               T. Reddy
Internet-Draft                                                  P. Patil
Intended status: Standards Track                                 D. Wing
Expires: August 29, 2013                                        R. Penno
                                                                   Cisco
                                                       February 25, 2013


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

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 August 29, 2013.

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 August 29, 2013                [Page 1]


Internet-Draft            PCP Auth Requirements            February 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 . . . . . . . . . . . . . . . . . . . . . 6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7



































Reddy, et al.            Expires August 29, 2013                [Page 2]


Internet-Draft            PCP Auth Requirements            February 2013


1.  Introduction

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


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


3.  Requirements

   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.

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

   REQ-2:  PCP Servers MUST be able to indicate that a request will not
      be processed without authentication.

   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.

   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.






Reddy, et al.            Expires August 29, 2013                [Page 3]


Internet-Draft            PCP Auth Requirements            February 2013


   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.

   REQ-6:  Clients that have authenticated with the server MUST verify
      the integrity of the contents of all unsolicited responses.

   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.

   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.

   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 PCP-base
      [I-D.ietf-pcp-base].  Other PCP drafts MUST evaluate if
      confidentiality is OPTIONAL or not for new PCP opcodes and options
      introduced.

   REQ-10:  The authentication mechanism SHOULD be immune to passive
      dictionary attacks.

   REQ-11:  PCP Authentication MUST ensure that an attacker snopping the
      PCP messages cannot guess the SA.

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

   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.

   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.






Reddy, et al.            Expires August 29, 2013                [Page 4]


Internet-Draft            PCP Auth Requirements            February 2013


   REQ-15:  For the scenarios described in REQ-13, PCP authentication
      mechanism MUST be functional across address and port translation,
      including NAPT64 and NAPT44.

   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.

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

   REQ-17:  PCP Proxy must also ensure message integrity after updating
      the PCP message for cases described in sections 6 and 7 of
      [I-D.ietf-pcp-proxy].

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

   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.

   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.


4.  Third Party Authorization

   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.



Reddy, et al.            Expires August 29, 2013                [Page 5]


Internet-Draft            PCP Auth Requirements            February 2013


   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.


5.  Other recommendations

   o  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).


6.  IANA Considerations

   This document does not require any action from IANA.


7.  Security Considerations

   This document does not define an architecture nor a protocol; as such
   it does not raise any security concerns.


8.  References

8.1.  Normative References

   [I-D.ietf-pcp-base]
              Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
              Selkirk, "Port Control Protocol (PCP)",
              draft-ietf-pcp-base-29 (work in progress), November 2012.

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





Reddy, et al.            Expires August 29, 2013                [Page 6]


Internet-Draft            PCP Auth Requirements            February 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-02
              (work in progress), February 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.


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


   Prashanth Patil
   Cisco Systems, Inc.
   Bangalore
   India

   Email: praspati@cisco.com











Reddy, et al.            Expires August 29, 2013                [Page 7]


Internet-Draft            PCP Auth Requirements            February 2013


   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 August 29, 2013                [Page 8]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/