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

Versions: (draft-wasserman-pcp-authentication) 00 01 02 03 04

Network Working Group                                       M. Wasserman
Internet-Draft                                                S. Hartman
Intended status: Experimental                          Painless Security
Expires: April 05, 2014                                         D. Zhang
                                                                  Huawei
                                                        October 02, 2013


          Port Control Protocol (PCP) Authentication Mechanism
                    draft-ietf-pcp-authentication-02

Abstract

   An IPv4 or IPv6 host can use the Port Control Protocol (PCP) to
   flexibly manage the IP address and port mapping information on
   Network Address Translators (NATs) or firewalls, to facilitate
   communications with remote hosts.  However, the un-controlled
   generation or deletion of IP address mappings on such network devices
   may cause security risks and should be avoided.  In some cases the
   client may need to prove that it is authorized to modify, create or
   delete PCP mappings.  This document proposes an in-band
   authentication mechanism for PCP that can be used in those cases.
   The Extensible Authentication Protocol (EAP) is used to perform
   authentication between PCP devices.

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 April 05, 2014.

Copyright Notice

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





Wasserman, et al.        Expires April 05, 2014                 [Page 1]

Internet-Draft             PCP Authentication               October 2013


   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
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Protocol Details  . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Session Initiation  . . . . . . . . . . . . . . . . . . .   5
     3.2.  Session Termination . . . . . . . . . . . . . . . . . . .   7
     3.3.  Session Re-Authentication . . . . . . . . . . . . . . . .   7
   4.  PA Security Association . . . . . . . . . . . . . . . . . . .   8
   5.  Result Code . . . . . . . . . . . . . . . . . . . . . . . . .   9
   6.  Packet Format . . . . . . . . . . . . . . . . . . . . . . . .  10
     6.1.  Packet Format of PCP Auth Messages  . . . . . . . . . . .  10
     6.2.  Authentication OpCode Format  . . . . . . . . . . . . . .  11
     6.3.  Nonce Option  . . . . . . . . . . . . . . . . . . . . . .  12
     6.4.  Authentication Tag Option . . . . . . . . . . . . . . . .  12
     6.5.  EAP Payload Option  . . . . . . . . . . . . . . . . . . .  13
     6.6.  PRF Option  . . . . . . . . . . . . . . . . . . . . . . .  13
     6.7.  MAC Algorithm Option  . . . . . . . . . . . . . . . . . .  14
     6.8.  Session Lifetime Option . . . . . . . . . . . . . . . . .  14
     6.9.  Received Packet Option  . . . . . . . . . . . . . . . . .  14
   7.  Processing Rules  . . . . . . . . . . . . . . . . . . . . . .  15
     7.1.  Authentication Data Generation  . . . . . . . . . . . . .  15
     7.2.  Authentication Data Validation  . . . . . . . . . . . . .  15
     7.3.  Retransmission Policies . . . . . . . . . . . . . . . . .  16
     7.4.  Sequence Number . . . . . . . . . . . . . . . . . . . . .  16
     7.5.  MTU Considerations  . . . . . . . . . . . . . . . . . . .  17
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  18
   11. Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     11.1.  Changes from wasserman-pcp-authentication-02 to ietf-
            pcp-authentication-00  . . . . . . . . . . . . . . . . .  18
     11.2.  Changes from wasserman-pcp-authentication-01 to -02  . .  18
     11.3.  Changes from ietf-pcp-authentication-00 to -01 . . . . .  18
     11.4.  Changes from ietf-pcp-authentication-01 to -02 . . . . .  18
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  19
     12.2.  Informative References . . . . . . . . . . . . . . . . .  19



Wasserman, et al.        Expires April 05, 2014                 [Page 2]

Internet-Draft             PCP Authentication               October 2013


   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   Using the Port Control Protocol (PCP) [RFC6887], an IPv4 or IPv6 host
   can flexibly manage the IP address mapping information on its network
   address translators (NATs) and firewalls, and control their policies
   in processing incoming and outgoing IP packets.  Because NATs and
   firewalls both play important roles in network security
   architectures, there are many situations in which authentication and
   access control are required to prevent un-authorized users from
   accessing such devices.  This document proposes a PCP security
   extension which enables PCP servers to authenticate their clients
   with Extensible Authentication Protocol (EAP).  The EAP messages are
   encapsulated within PCP packets during transportation.

   The following issues are considered in the design of this extension:

   o  Loss of EAP messages during transportation

   o  Disordered delivery of EAP messages

   o  Generation of transport keys

   o  Integrity protection and data origin authentication for PCP
      messages

   o  Algorithm agility

   The mechanism described in this document meets the security
   requirements to address the Advanced Threat Model described in the
   base PCP specification [RFC6887].  This mechanism can be used to
   secure PCP in the following situations::

   o  On security infrastructure equipment, such as corporate firewalls,
      that does not create implicit mappings.

   o  On equipment (such as CGNs or service provider firewalls) that
      serve multiple administrative domains and do not have a mechanism
      to securely partition traffic from those domains.

   o  For any implementation that wants to be more permissive in
      authorizing explicit mappings than it is in authorizing implicit
      mappings.

   o  For implementations that support the THIRD_PARTY Option (unless
      they can meet the constraints outlined in Section 14.1.2.2).




Wasserman, et al.        Expires April 05, 2014                 [Page 3]

Internet-Draft             PCP Authentication               October 2013


   o  For implementations that wish to support any deployment scenario
      that does not meet the constraints described in Section 14.1.

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

   Most of the terms used in this document are introduced in [RFC6887].

   PCP Client: A PCP device (e.g., a host) which is responsible for
   issuing PCP requests to a PCP server.  In this document, a PCP client
   is also a EAP peer [RFC3748], and it is the responsibility of a PCP
   client to provide the credentials when authentication is required.

   PCP Server: A PCP device (e.g., a NAT or a firewall) that implements
   the server-side of the PCP protocol, via which PCP clients request
   and manage explicit mappings.  In this document, a PCP server is
   integrated with an EAP authenticator [RFC3748].  Therefore, when
   necessary, a PCP server can verify the credentials provided by a PCP
   client and make an access control decision based on the
   authentication result.

   PCP Authentication (PCP Auth) Session: A series of PCP message
   exchanges transferred between a PCP client and a PCP server.  The PCP
   message involved within a session includes the PCP Auth messages used
   to perform authentication, key distribution and session management,
   and the common PCP messages secured with the distributed keys.  Each
   PCP Auth session is assigned a distinctive Session ID.

   Session Partner: A PCP device involved within a PCP Auth session.
   Each PCP Auth session has two session partners (a PCP server and a
   PCP client).

   Session Lifetime: The life period associated with a PCP Auth session,
   which decides the lifetime of the current authorization given to the
   PCP client.

   PCP Security Association (PCP SA): A PCP security association is
   formed between a PCP client and a PCP server by sharing cryptographic
   keying material and associated context.  The formed duplex security
   association is used to protect the bidirectional PCP signaling
   traffic between the PCP client and PCP server.

   Master Session Key (MSK): A key derived by the partners of a PCP Auth
   session, using an EAP key generating method (e.g., the one defined in
   [RFC5448]).



Wasserman, et al.        Expires April 05, 2014                 [Page 4]

Internet-Draft             PCP Authentication               October 2013


   PCP Authentication (PCP Auth) message: A PCP message containing an
   Authentication OpCode.  Particularly, a PCP Auth message sent from a
   PCP server to a PCP client is referred to as a PCP-Auth-Request,
   while PCP Auth message sent from a PCP client to a PCP server is
   referred to as a PCP-Auth-Answer.  Therefore, a PCP-Auth-Request is
   actually a PCP response message specified [RFC6887], and a PCP-Auth-
   Answer is a PCP request message.

   Common PCP message: A PCP message which does not contain an
   Authentication OpCode.  This document specifies an authentication
   option to provide integrity protection and message origin
   authentication for the common PCP messages.

3.  Protocol Details

3.1.  Session Initiation

   At be beginning of a PCP Auth Session, a set of PCP Auth messages
   need to be exchanged between two PCP devices in order to carry out an
   EAP authentication process.  Each PCP Auth message is attached with
   an Authentication OpCode and may optionally contain the Options for
   various purposes (e.g., transporting authentication messages and
   session managements).  The Authentication OpCode consists of two
   fields: Session ID, and Sequence Number.  The Session ID field is
   used to identify the session to which the message belongs.  The
   sequence number field is used to detect the disorder or the
   duplication occurred during packet delivery.

   When a PCP client intends to proactively initiate a PCP Auth session
   with a PCP server, it sends a PCP-Auth-Initiation message (a PCP-
   Auth-Answer message with the result code "INITIATION") to the PCP
   server.  In the message, the Session ID and Sequence Number fields of
   the Authentication OpCode are set as 0.  The PCP client MAY also
   append a nonce option which consists of a random nonce with PCP-Auth-
   Initiation message.  After receiving the PCP-Auth-Initiation, if the
   PCP server would like to initiate a PCP Auth session, it will reply
   with a PCP-Auth-Request which contains an EAP Identity Request.  The
   Sequence Number field in the PCP-Auth-Request is set as 0, and the
   Session ID field MUST be filled with the session identifier assigned
   by the PCP server for this session.  If there is a nonce option in
   the received PCP-Auth-Initiation message, the PCP-Auth-Request MUST
   be attached with a nonce option which contains the nonce value
   learned from the PCP client.  The nonce will then be used by the PCP
   client to check the freshness of the PCP-Auth-Request from the PCP
   server.  From now on, every PCP Auth message within this session will
   use this session identifier to distinguish itself from the messages
   not belonging to the session.  When receiving a PCP Auth message from
   an unknown session, a PCP device MUST discard the message silently.



Wasserman, et al.        Expires April 05, 2014                 [Page 5]

Internet-Draft             PCP Authentication               October 2013


   If the PCP client intends to simplify the authentication process, it
   can append an EAP Identity Response message within the PCP-Auth-
   Initiation message so as to inform the PCP server that it would like
   to perform EAP authentication and skip the step of waiting for the
   EAP Identity Request.

   In the scenario where a PCP server receives a common PCP request
   message from a PCP client which needs to be authenticated, the PCP
   server can reply with a PCP-Auth-Request to initiate a PCP Auth
   session; the result code field of the PCP-Auth-Request is set as
   AUTHENTICATION-REQUIRED.  In addition, the PCP server MUST assign a
   session ID for the session and transfer it within the PCP-Auth-
   Request.  The Sequence Number field in the PCP-Auth-Request is set as
   0.  In the PCP Auth messages exchanged afterwards in this session,
   the session ID MUST be used in order to help session partners
   distinguish the messages within this session from those not within.
   When the PCP client receives this initial PCP-Auth-Request message
   from the PCP server, it can reply with a PCP-Auth-Answer message or
   silently discard the request message according to its local policies.
   In the PCP-Auth-Answer message, the PCP client MAY append a nonce
   option which consists of a random nonce with PCP-Auth-Initiation
   message.  If so, in the next PCP-Auth-Request message, the PCP sever
   MUST forward the nonce back within a nonce option.

   In a PCP Auth session, PCP-Auth-Request messages are sent from PCP
   servers to PCP clients while PCP-Auth-Answer messages are only sent
   from PCP clients to PCP servers.  Correspondently, an EAP request
   message MUST be transported within a PCP-Auth-Request message, and an
   EAP answer message MUST be transported within a PCP-Auth-Answer
   message.  When a PCP device receives a PCP-Auth message from its
   partner and cannot generate a response within a pre-specified period
   due to certain reasons (e.g., waiting for human input to construct a
   EAP message), the PCP device MAY reply with a PCP-Auth-Acknowledge
   message (a PCP-Auth message with the result code "PACKET-RECEIVED-
   ACK") to notify the packet has been received, and thus un-necessarily
   retransmission of the PCP Auth message can be avoided.

   In this approach, it is mandated for a PCP client and a PCP server to
   perform a key-generating EAP method in authentication.  Therefore,
   after a successful authentication procedure, a Master Session Key
   (MSK) will be generated.  If the PCP client and the PCP server want
   to generate a traffic key using the MSK, they need to agree upon a
   Pseudo-Random Function (PRF) for the transport key derivation and a
   MAC algorithm to provide data origin authentication for subsequent
   PCP packets.  On this occasion, the PCP server needs to append the
   initial PCP-Auth-Request message with a set of PRF Options and MAC
   Algorithm Options.  Each PRF Option contains a PRF that the PCP
   server supports, and each MAC Algorithm Option contains a MAC



Wasserman, et al.        Expires April 05, 2014                 [Page 6]

Internet-Draft             PCP Authentication               October 2013


   (Message Authentication Code) algorithm that the PCP server supports.
   After receiving the request, the PCP client selects a PRF and a MAC
   algorithm which it would like to use, and sends back a PCP-Auth-
   Answer with a PRF Option and a MAC Algorithm Option for the selected
   algorithm.

   The last PCP-Auth-Request message transported within a PCP Auth
   session carries the EAP authentication and PCP authorization results.
   If the EAP authentication succeeds, the result code of the last PCP-
   Auth-Request is AUTHENTICATION-SUCCEED.  In this case, before sending
   out the PCP-Auth-Request, the PCP server must derive a transport key
   and use it to generate digests to protect the integrity and
   authenticity of the PCP-Auth-Request.  Such digests are transported
   within Authentication Tag Options.  In addition, the PCP-Auth-Request
   may need to be appended with a Session Lifetime Option which includes
   the life-time of the PCP Auth session (i.e., the life-time of the
   MSK).  If the PCP client also authenticate the PCP server, the PCP
   client then generates the PCP SA and uses the derived traffic key to
   secure the packet receiving acknowledgement.  From then on, all the
   PCP messages within the session are secured with the traffic key and
   the MAC algorithm sepcified in the PCP SA, unless re-authentication
   is performed.  If the EAP authentication fails, the result code of
   the last PCP-Auth-Request is AUTHENTICATION-FAILED.  If the EAP
   authentication succeeds but Authorization fails, the result code of
   the last PCP-Auth-Request is AUTHORIZATION-FAILED.  In the latter two
   cases, the PCP Auth session MUST be terminated immediately after the
   last PCP authentication message exchange.

3.2.  Session Termination

   A PCP Auth session can be explicitly terminated by sending a
   termination-indicating PCP Auth message (a PCP Auth message with a
   result code "SESSION-TERMINATION" ) from either session partner.
   After receiving a termination-indicating message from the session
   partner, a PCP device MUST respond with a termination-indicating PCP
   Auth message and remove the PCP Auth SA immediately.  When the
   session partner initiating the termination process receives the
   acknowledge message, it will remove the associated PCP Auth SA
   immediately.

3.3.  Session Re-Authentication

   A session partner may select to perform EAP re-authentication if it
   would like to update the PCP SA (e.g., update the MSK, or extend the
   session life period) instead of initiating a new PCP Auth session.

   When the PCP server initiates re-authentication, it sends a PCP-Auth-
   Request message containing the EAP message for re-authentication to



Wasserman, et al.        Expires April 05, 2014                 [Page 7]

Internet-Draft             PCP Authentication               October 2013


   the PCP client.  The result code of the PCP-Auth-Request message is
   set to "RE-AUTHENTICATION", which indicates the message is for an re-
   authentication process.  If the PCP client would like to start the
   re-authentication, it will send an PCP-Auth-Answer message containing
   the EAP message for re-authentication to the PCP server, The result
   code of the PCP-Auth-Answer message is set to "RE-AUTHENTICATION".
   Then, the session partners exchange PCP Auth messages to transfer EAP
   messages for the re-authentication.  During the re-authentication
   procedure, the session partners protect the integrity of PCP Auth
   messages with the key and MAC algorithm specified in the current PCP
   SA; the sequence numbers associated with the packet will never be
   rolled back and keep increasing according to Section 6.3.

   If the EAP re-authentication succeeds, the result code of the last
   PCP-Auth-Request is "AUTHENTICATION-SUCCEED".  In this case, before
   sending out the PCP-Auth-Request, the PCP server must update the SA
   and use the new key to generate digests to protect the integrity and
   authenticity of the PCP-Auth-Request and any subsequent PCP message.
   In addition, the PCP-Auth-Request MAY be appended with a Session
   Lifetime Option which indicates the new life-time of the PCP Auth
   session.

   If the EAP authentication fails, the result code of the last PCP-
   Auth-Request is "AUTHENTICATION-FAILED".  If the EAP authentication
   succeeds but Authorization fails, the result code of the last PCP-
   Auth-Request is "AUTHORIZATION-FAILED".  In the latter two cases, the
   PCP Auth session MUST be terminated immediately after the last PCP
   authentication message exchange.

4.  PA Security Association

   At the beginning of a PCP Auth session, a session SHOULD generate a
   PCP Auth SA to maintain its state information during the session.
   The parameters of a PCP Auth SA are listed as follows:

   o  IP address and UDP port number of the PCP client

   o  IP address and UDP port number of the PCP server

   o  Session Identifier

   o  Sequence number for the next outgoing PCP message

   o  Sequence number for the next incoming PCP message

   o  Last outgoing message payload

   o  Retransmission interval



Wasserman, et al.        Expires April 05, 2014                 [Page 8]

Internet-Draft             PCP Authentication               October 2013


   o  MSK: The master session key generated by the EAP method.

   o  MAC algorithm: The algorithm that the transport key should use to
      generate digests for PCP messages.

   o  Pseudo-random function: The pseudo random function negotiated in
      the initial PCP-Auth-Request and PCP-Auth-Answer exchange for the
      transport key derivation

   o  Transport key: the key derived from the MSK to provide integrity
      protection and data origin authentication for the messages in the
      PCP Auth session.  The life-time of the transport key SHOULD be
      identical to the life-time of the session.

   o  The nonce selected by the PCP client at the initiation of the
      session.

   o  Key ID: the ID associated with Transport key.

   Particularly, the transport key is computed in the following way:
   Transport key = prf(MSK, "IETF PCP"| Session_ID| Nonce| key ID),
   where:

   o  The prf: The pseudo-random function assigned in the Pseudo-random
      function parameter.

   o  MSK: The master session key generated by the EAP method.

   o  "IETF PCP": The ASCII code representation of the non-NULL
      terminated string (excluding the double quotes around it).

   o  Session_ID: The ID of the session which the MSK is derived from.

   o  Nonce: The nonce selected by the client and transported in the
      Initial PCP-Auth-Answer packet.  If the PCP client does not select
      one, this value is set as 0.

   o  Key ID: The ID assigned for the traffic key.

5.  Result Code

   This message use the result code field specified in the PCP headers
   to transport the information for authentication and session
   management.  Particularly, the values of following result codes are
   specified.

      TBD INITIATION




Wasserman, et al.        Expires April 05, 2014                 [Page 9]

Internet-Draft             PCP Authentication               October 2013


      TBD PACKET-RECEIVED-ACK

      TBD AUTHENTICATION-REQUIRED

      TBD AUTHENTICATION-FAILED

      TBD AUTHENTICATION-SUCCEED

      TBD AUTHORIZATION-FAILED

      TBD SESSION-TERMINATION

6.  Packet Format

6.1.  Packet Format of PCP Auth Messages

   The format of PCP-Auth-request messages is identical to the response
   packet format specified in Section 7.2 of [RFC6887].

   As illustrated in Figure 1, the PCP-Auth-Answer messages use the
   requester header specified in Section 7.1 of [RFC6887].  The only
   difference is that eight reserved bits are used to transfer the
   result codes (e.g., "INITIATION").  Other fields in Figure 1 are
   described in Section 7.1 of [RFC6887].



























Wasserman, et al.        Expires April 05, 2014                [Page 10]

Internet-Draft             PCP Authentication               October 2013


         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  Version = 2  |R|   Opcode    |   Reserved    |  Result Code  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                 Requested Lifetime (32 bits)                  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        |            PCP Client's IP Address (128 bits)                 |
        |                                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        :                                                               :
        :             (optional) Opcode-specific information            :
        :                                                               :
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        :                                                               :
        :             (optional) PCP Options                            :
        :                                                               :
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                     Figure 1.  PCP-Auth-Answer message Format


6.2.  Authentication OpCode Format

   The following figure illustrates the format of an authentication
   OpCode:

      0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Session ID                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Sequence Number                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Session ID: This field contains a 32-bit PCP Auth session
      identifier.

      Sequence Number: This field contains a 32-bit sequence number.  In
      this solution, a sequence number needs to be incremented on every
      new (non-retransmission) outgoing packet in order to provide
      ordering guarantee for PCP.





Wasserman, et al.        Expires April 05, 2014                [Page 11]

Internet-Draft             PCP Authentication               October 2013


6.3.  Nonce Option

   Because the session identifier of PCP Auth session is determined by
   the PCP server, a PCP client does not know the session identifier
   which will be used when it sends out a PCP-Auth-Initiation message.
   In order to prevent an attacker from interrupting the authentication
   process by sending off-line generated PCP-Auth-Request messages, the
   PCP client needs to generate a random number as nonce in the PCP-
   Auth-Initiation message.  The PCP server will append the nonce within
   the initial PCP-Auth-Request message.  If the PCP-Auth-Request
   message does not carry the correct nonce, the message will be
   discarded silently.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Option Code  |  Reserved     |       Option-Length           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Nonce                                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Option-Length: The length of the Nonce Option (in octet),
      including the 4 octet fixed header and the variable length of the
      authentication data.

      Nonce: A random 32 bits number which is transported within a PCC-
      Initiate message and the corresponding reply message from the PCP
      server.

6.4.  Authentication Tag Option

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Option Code  |  Reserved     |       Option-Length           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Session ID                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Key ID                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                Authentication Data (Variable)                 |
     ~                                                               ~
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Wasserman, et al.        Expires April 05, 2014                [Page 12]

Internet-Draft             PCP Authentication               October 2013


      Option-Length: The length of the Authentication Tag Option (in
      octet), including the 12 octet fixed header and the variable
      length of the authentication data.

      Session ID: A 32-bit field used to indicates the identifier of the
      session that the message belongs to and identifies the secret key
      used to create the message digest appended to the PCP message.

      Key ID: The ID associated with the traffic key used to generate
      authentication data.  This field is filled with zero if MSK is
      directly used to secure the message.

      Authentication Data: A variable-length field that carries the
      Message Authentication Code for the PCP packet.  The generation of
      the digest can be various according to the algorithms specified in
      different PCP SAs.  This field MUST end on a 32-bit boundary,
      padded with 0's when necessary.

6.5.  EAP Payload Option

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Option Code  |  Reserved     |       Option-Length           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                           EAP Message                         |
     ~                                                               ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Option-Length: The length of the EAP Payload Option (in octet),
      including the 4 octet fixed header and the variable length of the
      EAP message.

      EAP Message: The EAP message transferred.  Note this field MUST
      end on a 32-bit boundary, padded with 0's when necessary.

6.6.  PRF Option











Wasserman, et al.        Expires April 05, 2014                [Page 13]

Internet-Draft             PCP Authentication               October 2013


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Option Code  |  Reserved     |       Option-Length           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          PRF                                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   PRF: The Pseudo-Random Function which the sender supports to generate
   an MSK.  This field contains an IKEv2 Transform ID of Transform Type
   2 [RFC4306].

6.7.  MAC Algorithm Option

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Option Code  |  Reserved     |       Option-Length           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    MAC Algorithm ID                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   MAC Algorithm ID: Indicate the MAC algorithm which the sender
   supports to generate authentication data.  The MAC Algorithm ID field
   contains an IKEv2 Transform ID of Transform Type 3 [RFC4306].

6.8.  Session Lifetime Option

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Option Code  |  Reserved     |       Option-Length           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Session Lifetime                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Session Lifetime: The life time of the PCP Auth Session, which is
   decided by the authorization result.

6.9.  Received Packet Option

   This option is used in a PCP-Auth-Acknowledgement message to indicate
   a packet with the contained sequence number has been received.





Wasserman, et al.        Expires April 05, 2014                [Page 14]

Internet-Draft             PCP Authentication               October 2013


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Option Code  |  Reserved     |       Option-Length           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Received Sequence Number                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Received Sequence Number: The sequence number of the last received
   PCP packet.

7.  Processing Rules

7.1.  Authentication Data Generation

   If a PCP SA is generated as the result of a successful EAP
   authentication process, every subsequent PCP message within the
   session MUST carry an Authentication Tag Option which contains the
   digest of the PCP message for data origin authentication and
   integrity protection.

   Before generating a digest for a PCP message, a device needs to first
   select a traffic key in the session and append the Authentication Tag
   Option at the end of the PCP message being protected.  The length of
   the Authentication Data field is decided by the MAC algorithm adopted
   in the session.  The device then fills the Session ID field and the
   PCP SA ID field, and sets the Authentication Data field to 0.  After
   this, the device generates a digest for the entire PCP message
   (including the PCP header and Authentication Tag Option) with the MAC
   algorithm and the selected traffic key, and input the generated
   digest into the Authentication Data field.

7.2.  Authentication Data Validation

   When a device receives a PCP packet with an Authentication Tag
   Option, it needs to use the session ID transported in the option to
   locate the proper SA, and then find the associated transport key
   (using key ID) and the MAC algorithm.  If no proper SA is found, the
   PCP packet MUST be discarded silently.  After storing the value of
   the Authentication field of the Authentication Tag Option, the device
   fills the Authentication field with zeros.  Then, the device
   generates a digest for the packet (including the PCP header and
   Authentication Tag Option) with the transport key and the MAC
   algorithm found in the first step.  If the value of the newly
   generated digest is identical to the stored one, the device can
   ensure that the packet has not been tampered with, and the validation
   succeeds.  Otherwise, the packet MUST be discarded.



Wasserman, et al.        Expires April 05, 2014                [Page 15]

Internet-Draft             PCP Authentication               October 2013


7.3.  Retransmission Policies

   In order to provide reliable transmission over PCP messages, the
   retransmission poclies needs to be considered.

   In the base PCP protocol, only PCP clients are responsible for
   reliable delivery of PCP request messages according to policies
   specified in Section 8.1.1 of [RFC6887], However, in this document,
   both PCP clients and PCP servers need to provide reliable delivery of
   PCP Auth messages.  Therefore, such retransmission policy can be also
   applied by the PCP servers.

7.4.  Sequence Number

   PCP adopts UDP to transport signaling messages.  As an un-reliable
   transport protocol, UDP does not guarantee ordered packet delivery
   and does not provide any protection from packet loss.  In order to
   ensure the EAP messages are exchanged in a reliable way, every PCP
   packet exchanged during EAP authentication must carry an
   monotonically increasing sequence number.  During a PCP Auth session,
   a PCP device needs to maintain two sequence numbers, one for incoming
   packets and one for outgoing packets.  When generating an outgoing
   PCP packet, the device attaches the outgoing sequence number to the
   packet and increments the sequence number maintained in the SA by 1.
   When receiving a PCP packet from its session partner, the device will
   not accept it if the sequence number carried in the packet does not
   match the incoming sequence number the device maintains.  After
   confirming that the received packet is valid, the device increments
   the incoming sequence number maintained in the SA by 1.

   The above rules are not applied to PCP-Auth-Acknowledgement messages
   whose result code fields are set as PACKET-RECEIVED-ACK.  This type
   of message is optionally used to avoid un-necessary packet
   retransmission and the reliable transmission does not have to be
   guaranteed.  Therefore, when receiving or sending out a PCP-Auth-
   Acknowledgement message, the device MUST not increase the
   corresponding sequence number stored in the SA.  Otherwise, the lost
   of a PCP-Auth-Acknowledgement message during transportation will
   cause the mismatching issues with the sequence numbers.

   Another exception is message retransmission.  When a device does not
   receive any response from its session partner in a certain period, it
   needs to retransmit the last outgoing PCP Auth message with a limited
   rate.  The duplicate messages and the original message MUST use the
   identical sequence number.  When the device receives such duplicate
   PCP Auth messages from its session partner, it MUST try to answer
   them by sending the last outgoing PCP Auth message with a limited
   rate unless it has received another valid message with a larger



Wasserman, et al.        Expires April 05, 2014                [Page 16]

Internet-Draft             PCP Authentication               October 2013


   sequence number from its session.  In such cases, the maintained
   incoming and outgoing sequence numbers will not be affected by the
   message retransmission.

7.5.  MTU Considerations

   EAP methods are responsible for MTU handling, so no special
   facilities are required in this protocol to deal with MTU issues.

8.  IANA Considerations

   TBD

9.  Security Considerations

   This section applies only to the in-band key management mechanism.
   It will need to be updated if the WG choose to pursue the out-of-band
   key management mechanism discussed above.

   In this work, after a successful EAP authentication process performed
   between two PCP devices, a MSK will be exported.  The MSK can be used
   to derive the transport keys to generate MAC digests for subsequent
   PCP message exchanges.  This work does not exclude the possibility of
   using the MSK to generate keys for different security protocols to
   enable per-packet cryptographic protection.  The methods of deriving
   the transport key for the security protocols is out of scope of this
   document.

   However, before a transport key has been generated, the PCP Auth
   messages exchanged within a PCP Auth session have little
   cryptographic protection, and if there is no already established
   security channel between two session partners, these messages are
   subject to man-in-the-middle attacks and DOS attacks.  For instance,
   the initial PCP-Auth-Request and PCP-Auth-Answer exchange is
   vulnerable to spoofing attacks as these messages are not
   authenticated and integrity protected.  In addition, because the PRF
   and MAC algorithms are transported at this stage, an attacker may try
   to remove the PRF and MAC options containing strong algorithms from
   the initial PCP-Auth-Request message and force the client choose the
   weakest algorithms.  Therefore, the server needs to guarantee that
   all the PRF and MAC algorithms it provids support are strong enough.










Wasserman, et al.        Expires April 05, 2014                [Page 17]

Internet-Draft             PCP Authentication               October 2013


   In order to prevent very basic DOS attacks, a PCP device SHOULD
   generate state information as little as possible in the initial PCP-
   Auth-Request and PCP-Auth-Answer exchanges.  The choice of EAP method
   is also very important.  The selected EAP method must be resilient to
   the attacks possibly in an insecure network environment, and the
   user-identity confidentiality, protection against dictionary attacks,
   and session-key establishment must be supported.

10.  Acknowledgements

11.  Change Log

11.1.  Changes from wasserman-pcp-authentication-02 to ietf-pcp-
       authentication-00

   o  Added discussion of in-band and out-of-band key management
      options, leaving choice open for later WG decision.

   o  Removed support for fragmenting EAP messages, as that is handled
      by EAP methods.

11.2.  Changes from wasserman-pcp-authentication-01 to -02

   o  Add a nonce into the first two exchanged PCP Auth message between
      the PCP client and PCP server.  When a PCP client initiate the
      session, it can use the nonce to detect offline attacks.

   o  Add the key ID field into the authentication tag option so that a
      MSK can generate multiple traffic keys.

   o  Specify that when a PCP device receives a PCP-Auth-Request or a
      PCP-Auth-Answer message from its partner the PCP device needs to
      reply with a PCP-Auth-Acknowledge message to indicate that the
      message has been received.

   o  Add the support of fragmenting EAP messages.

11.3.  Changes from ietf-pcp-authentication-00 to -01

   o  Editorial changes, added use cases to introduction.

11.4.  Changes from ietf-pcp-authentication-01 to -02

   o  Add the support of re-authentication initiated by PCP server.







Wasserman, et al.        Expires April 05, 2014                [Page 18]

Internet-Draft             PCP Authentication               October 2013


   o  Specify that when a PCP device receives a PCP-Auth-Request or a
      PCP-Auth-Answer message from its partner the PCP device MAY reply
      with a PCP-Auth-Acknowledge message to indicate that the message
      has been received.

   o  Discuss the format of the PCP-Auth-Acknowledge message.

   o  Remove the redundant information from the Auth OpCode, and specify
      new result codes transported in PCP packet headers

12.  References

12.1.  Normative References

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

12.2.  Informative References

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
              3748, June 2004.

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
              4306, December 2005.

   [RFC5191]  Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
              Yegin, "Protocol for Carrying Authentication for Network
              Access (PANA)", RFC 5191, May 2008.

   [RFC5448]  Arkko, J., Lehtovirta, V., and P. Eronen, "Improved
              Extensible Authentication Protocol Method for 3rd
              Generation Authentication and Key Agreement (EAP-AKA')",
              RFC 5448, May 2009.

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

Authors' Addresses











Wasserman, et al.        Expires April 05, 2014                [Page 19]

Internet-Draft             PCP Authentication               October 2013


   Margaret Wasserman
   Painless Security
   356 Abbott Street
   North Andover, MA  01845
   USA

   Phone: +1 781 405 7464
   Email: mrw@painless-security.com
   URI:   http://www.painless-security.com


   Sam Hartman
   Painless Security
   356 Abbott Street
   North Andover, MA  01845
   USA

   Email: hartmans@painless-security.com
   URI:   http://www.painless-security.com


   Dacheng Zhang
   Huawei
   Beijing
   China

   Email: zhangdacheng@huawei.com
























Wasserman, et al.        Expires April 05, 2014                [Page 20]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/