Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7652.
Expired & archived
Authors Margaret Cullen , Sam Hartman , Dacheng Zhang
Last updated 2013-04-22 (Latest revision 2012-10-19)
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 7652 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-pcp-authentication-01
Network Working Group                                       M. Wasserman
Internet-Draft                                                S. Hartman
Intended status: Experimental                          Painless Security
Expires: April 22, 2013                                         D. Zhang
                                                                  Huawei
                                                        October 19, 2012

          Port Control Protocol (PCP) Authentication Mechanism
                  draft-ietf-pcp-authentication-01.txt

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 22, 2013.

Copyright Notice

   Copyright (c) 2012 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

Wasserman, et al.        Expires April 22, 2013                 [Page 1]
Internet-Draft             PCP Authentication               October 2012

   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.  Separate vs. Inline Key Management . . . . . . . . . . . . . .  5
   4.  Separate Key Management  . . . . . . . . . . . . . . . . . . .  5
   5.  Protocol Details . . . . . . . . . . . . . . . . . . . . . . .  6
     5.1.  Session Initiation . . . . . . . . . . . . . . . . . . . .  6
     5.2.  Session Termination  . . . . . . . . . . . . . . . . . . .  8
   6.  PA Security Association  . . . . . . . . . . . . . . . . . . .  8
   7.  Packet Format  . . . . . . . . . . . . . . . . . . . . . . . .  9
     7.1.  Authentication OpCode Format . . . . . . . . . . . . . . .  9
     7.2.  Nonce Option . . . . . . . . . . . . . . . . . . . . . . . 11
     7.3.  Authentication Tag Option  . . . . . . . . . . . . . . . . 11
     7.4.  EAP Payload Option . . . . . . . . . . . . . . . . . . . . 12
     7.5.  PRF Option . . . . . . . . . . . . . . . . . . . . . . . . 12
     7.6.  Hash Algorithm Option  . . . . . . . . . . . . . . . . . . 13
     7.7.  Session Lifetime Option  . . . . . . . . . . . . . . . . . 13
   8.  Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 13
     8.1.  Authentication Data Generation . . . . . . . . . . . . . . 13
     8.2.  Authentication Data Validation . . . . . . . . . . . . . . 14
     8.3.  Sequence Number  . . . . . . . . . . . . . . . . . . . . . 14
     8.4.  Retransmission Policies  . . . . . . . . . . . . . . . . . 15
     8.5.  MTU Considerations . . . . . . . . . . . . . . . . . . . . 16
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     12.1. Changes from wasserman-pcp-authentication-02 to
           ietf-pcp-authentication-00 . . . . . . . . . . . . . . . . 17
     12.2. Changes from wasserman-pcp-authentication-01 to -02  . . . 17
     12.3. Changes from wasserman-pcp-authentication-00 to -01  . . . 18
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 18
     13.2. Informative References . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19

Wasserman, et al.        Expires April 22, 2013                 [Page 2]
Internet-Draft             PCP Authentication               October 2012

1.  Introduction

   Using the Port Control Protocol (PCP) [I-D.ietf-pcp-base], 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
   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 [I-D.ietf-pcp-base].  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).

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

Wasserman, et al.        Expires April 22, 2013                 [Page 3]
Internet-Draft             PCP Authentication               October 2012

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
   [I-D.ietf-pcp-base].

   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 in order
   to perform authentication, authorization, key distribution and
   secured PCP communication.  Each PCP Auth session is assigned a
   distinctive Session ID.  The PCP devices involved within a PCP Auth
   session are called session partners.  A PCP Auth session has two
   session partners.

   Session Lifetime: The life period associated with a PCP Auth session,
   which decided 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]).

   PCP Auth (PCP Authentication) message: A PCP message containing an
   Authentication OpCode for EAP authentication.

   non PCP Auth message: A PCP message which is not a PCP Auth message.

Wasserman, et al.        Expires April 22, 2013                 [Page 4]
Internet-Draft             PCP Authentication               October 2012

3.  Separate vs. Inline Key Management

   There is an open question in the working group regarding what
   approach should be used for PCP key management.  The precursor to
   this document originally proposed an inline key management approach
   using EAP directly over PCP.  There was an alternative proposal on
   the list to standardize a separate key management approach using PANA
   [RFC5191] (with EAP).  The WG will need to make a decision between
   these two approaches before this document can be completed.

   Both approaches for key management could be used with the integrity
   protection mechanism and options described later in this document.

4.  Separate Key Management

   The separate key management proposal involves running PANA between
   the end-points to dynamically generate a security association, and
   then using that security association to authenticate PCP message
   exchanges.

   In pricinpal, the PANA message can be transported either through the
   PCP port or through an different port.  The latter option has been
   abandoned by the working group since it may impose unnecessary
   management burdens and cause issues in securely binding the PCP
   session to the PANA session initiation.

   The first option can be further broken down into two apporaches: The
   PANA over PCP solution and the demultiplexing solution.  For the
   first approach [I-D.ohba-pcp-pana-encap], we would define an AVP for
   PANA to indicate that the PANA session was being used for PCP
   authentication, not for network access purposes.  For the second
   approach, we just re-use the PCP port to transport PANA message
   [I-D.ohba-pcp-pana].

   The first approach introduces little change on PANA.  Howerer, there
   are criticisms about the existence of overlapping fields on the PANA
   and PCP headers that need to be check for consistency.

   Compared with the first approach, the second approach does not have
   this problem.  However, addition work needs to be done to help an PCP
   implementation to distinguish a PANA message from a PCP message.

   There are some functions of PANA which are not necessary for PCP.
   For example, it would not be necessary for these servers to support
   IP Address Reconfiguration and re-authentication.  It may be possible
   to address this problem by defining a subset of the PANA protocol
   that can be run on PCP Servers if the same PANA server will not be

Wasserman, et al.        Expires April 22, 2013                 [Page 5]
Internet-Draft             PCP Authentication               October 2012

   used for network access.

   Once a secure session has been established using PANA, the Secure
   OpCode option described in this draft could be used to associate PCP
   requests with a particular PANA session.

   Although a separate key management approach using PANA has been
   discussed on the PCP mailing list, this approach would require
   further documentation if the WG decides to pursue it.

5.  Protocol Details

5.1.  Session Initiation

   To carry out an EAP authentication process between two PCP devices, a
   set of PCP Auth messages need to be exchanged.  A PCP Auth message
   contains an Authentication OpCode and associated Options.  The
   Authentication OpCode consists of three fields: Session ID, Flag, and
   Sequence Number.  The Session ID field is used to identify the
   session to which the message belongs.  The Flag field indicates the
   type of the PCP message.  The sequence number field is used to detect
   the disorder or the duplication occurred during packet delivery.

   The message exchanges conveyed within an PCP Auth session is
   introduced in the remainder section.

   When a PCP client intends to initiate a PCP Auth session with a PCP
   server, it sends a PCC-Initiation message to the PCP server.  In the
   message, the Session ID and Sequence Number fields of the
   Authentication OpCode are set as 0; the I bit is set.  The PCC-
   Initiation message is also attached with a nonce option which
   consists of a random nonce selected by the PCP client.  The nonce
   will be used by the PCP client to check the freshness of the initial
   message from the PCP server.  After receiving the PCC-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.  The PCP-Auth-Request
   needs to be attached with a nonce option which is learned from the
   PCP client.  From now on, every PCP Auth message within this session
   must be attached with the session identifier.  When receiving a PCP
   Auth message from an unknown session, a PCP device MUST discard the
   message silently.  If the PCP client intends to simplify the
   authentication process, it can append an EAP Identity Response
   message within the PCC-Initiation request so as to inform the PCP
   server that it would like to perform EAP authentication and skip the

Wasserman, et al.        Expires April 22, 2013                 [Page 6]
Internet-Draft             PCP Authentication               October 2012

   step of waiting for the EAP Identity Request.

   In the scenario where a PCP server receives a non-PA PCP 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.  In the PCP
   Auth messages exchanged afterwards in this session, the session ID
   MUST be appended.  Therefore, in the subsequent communication, the
   PCP client can distinguish the messages in this session from those in
   other sessions through the PCP server IP address and the session ID.
   When the PCP client receives the initial PCP-Auth-Request message
   from the PCP server, it can reply with a PCP-Auth-Answer message to
   continue the session or silently discard the request message
   according to its local policies.

   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.  Particularly, 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.  This solution is used to deal with the
   conditions where the device cannot generate a response within a pre-
   specified period due to certain reasons (e.g., waiting for human
   input to construct a EAP message).  Therefore, the partner does not
   have to un-necessarily retransmit the PCP message.

   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.  Similarly, each MAC Algorithm Option contains a MAC
   (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.

Wasserman, et al.        Expires April 22, 2013                 [Page 7]
Internet-Draft             PCP Authentication               October 2012

   The last PCP-Auth-Request message transported within a PCP Auth
   session carries the EAP authentication and PCP authorization results.
   The last PCP-Auth-Request and PCP-Auth-Answer messages MUST have the
   'C' (Complete) bit set.

   If the EAP authentication succeeds, the result code of the last PCP-
   Auth-Request is AUTHENTICATION-SUCCESS.  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 and any subsequent PCP message.
   Such digests are transported within Authentication Tag Options.  In
   addition, the PCP-Auth-Request needs to be appended with a Session
   Lifetime Option which indicates the life-time of the PCP Auth session
   (i.e., the life-time of the MSK).

   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.

5.2.  Session Termination

   A PCP Auth session can be explicitly terminated by sending a
   termination-indicating PCP Auth acknowledge message 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 Acknowledge 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.

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

Wasserman, et al.        Expires April 22, 2013                 [Page 8]
Internet-Draft             PCP Authentication               October 2012

   o  Sequence number for the next incoming PCP message

   o  Last outgoing message payload

   o  Retransmission interval

   o  MSK

   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.

   Particularly, the transport key is computed in the following way:
   Transport key = prf(MSK, "IETF PCP"| Session_ID, 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  Key ID: The ID assigned for the traffic key

7.  Packet Format

7.1.  Authentication OpCode Format

   The following figure illustrates the format of an authentication
   Opcode:

Wasserman, et al.        Expires April 22, 2013                 [Page 9]
Internet-Draft             PCP Authentication               October 2012

         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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |I C R K T S E|   Reserved      |          Result Code          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Session ID                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Sequence Number                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Flags: The Flags field is two octets.  The following bits are
      assigned:

      I (Initiation): This bit is set in a PCC-Initiation message.

      C (Complete): If the message is the last PCP-Auth-Request or PCP-
      Auth-Answer message in the session, this bit MUST be set.  For
      other messages, this bit MUST be cleared.

      R (Request): This bit is set in a PCP-Auth-Request message, and
      un-set in a PCP-Auth-Answer message.

      K (acKnowledgement): This bit is set and only set in a PCP-Auth-
      Acknowledgement message.

      T (Termination): If this bit is set in a PCP-Auth-Acknowledgement
      message, the message is used for session-termination indication.

      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.

      Result Code: This field is two octets.  The following values are
      defined:

         1 AUTHENTICATION-REQUIRED

         2 AUTHENTICATION-FAILED

         3 AUTHENTICATION-SUCCESS

Wasserman, et al.        Expires April 22, 2013                [Page 10]
Internet-Draft             PCP Authentication               October 2012

         4 AUTHORIZATION-FAILED

7.2.  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 PCC-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 PCC-
   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                                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

7.3.  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 22, 2013                [Page 11]
Internet-Draft             PCP Authentication               October 2012

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Option-Length: The length of the Authentication Tag Option (in
      octet), including the 8 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.

7.4.  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                         |
       ~                                                               ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

7.5.  PRF Option

Wasserman, et al.        Expires April 22, 2013                [Page 12]
Internet-Draft             PCP Authentication               October 2012

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

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

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

8.  Processing Rules

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

Wasserman, et al.        Expires April 22, 2013                [Page 13]
Internet-Draft             PCP Authentication               October 2012

   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 protected PCP message.  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.

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

8.3.  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.
   However, the above rules are not applied to PCP-Auth-Acknowledgement

Wasserman, et al.        Expires April 22, 2013                [Page 14]
Internet-Draft             PCP Authentication               October 2012

   messages.  When receiving or sending out a PCP-Auth-Acknowledgement
   message, the device does not increase the corresponding sequence
   number stored in the SA.  Another exception is message
   retransmission.  When a device does not receive any response message
   from its session partner in a certain period, it needs to retransmit
   the last sent message with a limited rate.  The duplicate messages
   and the original message MUST use the identical sequence number.
   When the device receives such duplicate messages from its session
   partner, it MUST try to answer them by sending the last outgoing
   message with a limited rate unless it has received another valid
   message with a larger sequence number from its session.  In such
   cases, the maintained incoming and outgoing sequence numbers will not
   be affected by the message retransmission.

8.4.  Retransmission Policies

   This work provides a retransmission mechanism for reliable PCP Auth
   message delivery.  The timer, the variables, and the rules used in
   this mechanism are adopted from PANA.

   The retransmission behavior is controlled and described by the
   following variables:

      RT: Retransmission timeout from the previous (re)transmission

      IRT: Base value for RT for the initial retransmission

      MRC: Maximum retransmission count

      MRT: Maximum retransmitting time interval

      RAND: Randomization factor

   With each message transmission or retransmission, the sender sets RT
   according to the rules given below.

   If RT expires before receiving any reply, the sender re-calculates RT
   and retransmits the message.  Each of the computations of a new RT
   includes a randomization factor (RAND), which is a random number
   chosen with a uniform distribution between -0.1 and +0.1.  The
   randomization factor is included to minimize the synchronization of
   messages.  The algorithm for choosing a random number does not need
   to be cryptographically sound.  The algorithm SHOULD produce a
   different sequence of random numbers from each invocation.  RT for
   the first message retransmission is based on IRT:

   RT = IRT

Wasserman, et al.        Expires April 22, 2013                [Page 15]
Internet-Draft             PCP Authentication               October 2012

   RT for each subsequent message retransmission is based on the
   previous value of RT (RTprev):

   RT = (2+RAND) * RTprev

   MRT specifies an upper bound on the value of RT (disregarding the
   randomization added by the use of RAND).  If MRT has a value of 0,
   there is no upper limit on the value of RT.  Otherwise:

   if (RT > MRT)

   RT = (1+RAND) * MRT

   MRC specifies an upper bound on the number of times a sender may
   retransmit a message.  Unless MRC is zero, the message exchange fails
   once the sender has transmitted the message MRC times.  In this case,
   the sender needs to start a session termination process illustrated
   in Section 3.2.

8.5.  MTU Considerations

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

9.  IANA Considerations

   TBD

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

Wasserman, et al.        Expires April 22, 2013                [Page 16]
Internet-Draft             PCP Authentication               October 2012

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

11.  Acknowledgements

12.  Change Log

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

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

Wasserman, et al.        Expires April 22, 2013                [Page 17]
Internet-Draft             PCP Authentication               October 2012

12.3.  Changes from wasserman-pcp-authentication-00 to -01

   o  Editorial changes, added use cases to introduction.

13.  References

13.1.  Normative References

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

13.2.  Informative 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-28 (work in progress), October 2012.

   [I-D.ohba-pcp-pana]
              Ohba, Y., Tanaka, Y., Das, S., Yegin, A., and T. Tsou,
              "Provisioning Message Authentication Key for PCP using
              PANA (Side-by-Side Approach)", draft-ohba-pcp-pana-03
              (work in progress), October 2012.

   [I-D.ohba-pcp-pana-encap]
              Ohba, Y., Yegin, A., and S. Das, "Provisioning Message
              Authentication Key for PCP using PANA (Encapsulation
              Approach)", draft-ohba-pcp-pana-encap-00 (work in
              progress), October 2012.

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

Wasserman, et al.        Expires April 22, 2013                [Page 18]
Internet-Draft             PCP Authentication               October 2012

Authors' Addresses

   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

   Phone:
   Fax:
   Email: zhangdacheng@huawei.com
   URI:

Wasserman, et al.        Expires April 22, 2013                [Page 19]