tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7652

 Errata 
Proposed STD
Pages: 34
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: PCP

Port Control Protocol (PCP) Authentication Mechanism

Part 1 of 2, p. 1 to 22
None       Next RFC Part

Updates:    6887


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                         M. Cullen
Request for Comments: 7652                                    S. Hartman
Updates: 6887                                          Painless Security
Category: Standards Track                                       D. Zhang
ISSN: 2070-1721
                                                                T. Reddy
                                                                   Cisco
                                                          September 2015


          Port Control Protocol (PCP) Authentication Mechanism

Abstract

   An IPv4 or IPv6 host can use the Port Control Protocol (PCP) to
   flexibly manage the IP address-mapping and port-mapping information
   on Network Address Translators (NATs) or firewalls to facilitate
   communication with remote hosts.  However, the uncontrolled
   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 describes 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.

   This document updates RFC 6887.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7652.

Page 2 
Copyright Notice

   Copyright (c) 2015 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
   described in the Simplified BSD License.

Top       Page 3 
Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Protocol Details  . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Session Initiation  . . . . . . . . . . . . . . . . . . .   6
       3.1.1.  Authentication Triggered by the Client  . . . . . . .   6
       3.1.2.  Authentication Triggered by the Server  . . . . . . .   7
       3.1.3.  Authentication Using EAP  . . . . . . . . . . . . . .   8
     3.2.  Recovery from Lost PA Session . . . . . . . . . . . . . .  10
     3.3.  Session Termination . . . . . . . . . . . . . . . . . . .  11
     3.4.  Session Re-authentication . . . . . . . . . . . . . . . .  11
   4.  PA Security Association . . . . . . . . . . . . . . . . . . .  12
   5.  Packet Format . . . . . . . . . . . . . . . . . . . . . . . .  14
     5.1.  Packet Format of PCP Auth Messages  . . . . . . . . . . .  14
     5.2.  Opcode-Specific Information of AUTHENTICATION Opcode  . .  16
     5.3.  NONCE Option  . . . . . . . . . . . . . . . . . . . . . .  16
     5.4.  AUTHENTICATION_TAG Option . . . . . . . . . . . . . . . .  17
     5.5.  PA_AUTHENTICATION_TAG Option  . . . . . . . . . . . . . .  18
     5.6.  EAP_PAYLOAD Option  . . . . . . . . . . . . . . . . . . .  19
     5.7.  PRF Option  . . . . . . . . . . . . . . . . . . . . . . .  19
     5.8.  MAC_ALGORITHM Option  . . . . . . . . . . . . . . . . . .  20
     5.9.  SESSION_LIFETIME Option . . . . . . . . . . . . . . . . .  20
     5.10. RECEIVED_PAK Option . . . . . . . . . . . . . . . . . . .  21
     5.11. ID_INDICATOR Option . . . . . . . . . . . . . . . . . . .  21
   6.  Processing Rules  . . . . . . . . . . . . . . . . . . . . . .  22
     6.1.  Authentication Data Generation  . . . . . . . . . . . . .  22
     6.2.  Authentication Data Validation  . . . . . . . . . . . . .  23
     6.3.  Retransmission Policies for PA Messages . . . . . . . . .  24
     6.4.  Sequence Numbers for PCP Auth Messages  . . . . . . . . .  25
     6.5.  Sequence Numbers for Common PCP Messages  . . . . . . . .  26
     6.6.  MTU Considerations  . . . . . . . . . . . . . . . . . . .  26
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  27
     7.1.  NONCE . . . . . . . . . . . . . . . . . . . . . . . . . .  28
     7.2.  AUTHENTICATION_TAG  . . . . . . . . . . . . . . . . . . .  28
     7.3.  PA_AUTHENTICATION_TAG . . . . . . . . . . . . . . . . . .  29
     7.4.  EAP_PAYLOAD . . . . . . . . . . . . . . . . . . . . . . .  29
     7.5.  PRF . . . . . . . . . . . . . . . . . . . . . . . . . . .  29
     7.6.  MAC_ALGORITHM . . . . . . . . . . . . . . . . . . . . . .  30
     7.7.  SESSION_LIFETIME  . . . . . . . . . . . . . . . . . . . .  30
     7.8.  RECEIVED_PAK  . . . . . . . . . . . . . . . . . . . . . .  30
     7.9.  ID_INDICATOR  . . . . . . . . . . . . . . . . . . . . . .  31
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  31
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  32
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  32
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  33
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  33
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  34

Top      ToC       Page 4 
1.  Introduction

   Using the Port Control Protocol (PCP) [RFC6887], an application can
   flexibly manage the IP address-mapping information on its network
   address translators (NATs) and firewalls and can 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 unauthorized users from
   accessing such devices.  This document defines a PCP security
   extension that enables PCP servers to authenticate their clients with
   the Extensible Authentication Protocol (EAP).  The EAP messages are
   encapsulated within PCP messages during transmission.

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

   o  Loss of EAP messages during transmission.

   o  Reordered 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 for specific traffic.

   o  On equipment (such as Carrier-Grade NATs (CGNs) or service
      provider firewalls) that serves 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 applications to create mappings for successful inbound
      communications destined to machines located behind a NAT or a
      firewall.

Top      ToC       Page 5 
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 software instance that is responsible for issuing
   PCP requests to a PCP server.  In this document, a PCP client is also
   an EAP peer [RFC3748], and it is the responsibility of a PCP client
   to provide the credentials when authentication is required.

   PCP server: A PCP software instance that resides on the
   PCP-controlled device that receives PCP requests from the PCP client
   and creates appropriate state in response to that request.  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 (PA) session: A series of PCP message exchanges
   transferred between a PCP client and a PCP server.  The PCP messages
   that are part of a given session include the PA messages used to
   perform EAP authentication, key distribution, and session management,
   as well as the common PCP messages secured with the keys distributed
   during authentication.  Each PA session is assigned a distinctive
   Session ID.

   Session partner: A PCP implementation involved in a PA session.  Each
   PA session has two session partners (a PCP server and a PCP client).

   PCP device: A PCP client or a PCP server.

   Session lifetime: The lifetime associated with a PA session.  The
   session lifetime of the PA session decides the lifetime of the
   current authorization given to the PCP client.

   PA Security Association (PCP SA): An association 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
   PA session, using an EAP key-generating method (e.g., the method
   defined in [RFC5448]).

Top      ToC       Page 6 
   PCP-Authentication (PA) message: A PCP message containing an
   AUTHENTICATION Opcode.  Specifically, a PA message sent from a
   PCP server to a PCP client is referred to as a PA-Server message,
   while a PA message sent from a PCP client to a PCP server is referred
   to as a PA-Client message.  Therefore, a PA-Server message is
   actually a PCP response message as specified in [RFC6887], and a
   PA-Client message is a PCP request message.  This document specifies
   an option -- the PA_AUTHENTICATION_TAG option defined in Section 5.5
   for PCP authentication -- to provide integrity protection and message
   origin authentication for PA messages.

   Common PCP message: A PCP message that does not contain an
   AUTHENTICATION Opcode.  This document specifies an AUTHENTICATION_TAG
   option to provide integrity protection and message origin
   authentication for the common PCP messages.

3.  Protocol Details

3.1.  Session Initiation

   At the beginning of a PA session, a PCP client and a PCP server need
   to exchange a series of PA messages in order to perform an EAP
   authentication process.  Each PA message MUST contain an
   AUTHENTICATION Opcode and may optionally contain a set of options for
   various purposes (e.g., transporting authentication messages and
   session management).  The Opcode-specific information in an
   AUTHENTICATION Opcode consists of two fields: Session ID and Sequence
   Number.  The Session ID field is used to identify the PA session to
   which the message belongs.  The Sequence Number field is used to
   detect whether reordering or duplication occurred during message
   delivery.

3.1.1.  Authentication Triggered by the Client

   When a PCP client intends to proactively initiate a PA session with a
   PCP server, it sends a PA-Initiation message (a PA-Client message
   with the result code INITIATION) to the PCP server.  Section 5.1
   updates the PCP request message format with result codes for the PCP
   authentication mechanism.  In the Opcode-specific information of the
   message, the Session ID and Sequence Number fields are set to zero.
   The PA-Client message MUST also contain a NONCE option (defined in
   Section 5.3) that consists of a random nonce.

   After receiving the PA-Initiation message, if the PCP server agrees
   to initiate a PA session with the PCP client, it will reply with a
   PA-Server message that contains an EAP request, and the Result Code
   field of this PA-Server message is set to AUTHENTICATION_REQUEST.  In
   addition, the server MUST assign a unique session identifier to

Top      ToC       Page 7 
   distinctly identify this session and insert the identifier into the
   Session ID field in the Opcode-specific information of the PA-Server
   message.  The Sequence Number field of the message is set to zero.
   The PA-Server message MUST contain a NONCE option so as to send the
   nonce value back.  The nonce will then be used by the PCP client to
   check the freshness of this message.  Subsequent PCP messages within
   this PA session MUST contain this session identifier.

          PCP                                               PCP
         client                                            server
           |-- PA-Initiation ------------------------------->|
           |    (Seq=0, rc=INITIATION, Session ID=0)         |
           |                                                 |
           |<-- PA-Server -----------------------------------|
           |     (Seq=0, Session ID=X, EAP request,          |
           |      rc=AUTHENTICATION_REQUEST)                 |
           |                                                 |
           |-- PA-Client ----------------------------------->|
           |    (Seq=1, Session ID=X, EAP response,          |
           |     rc=AUTHENTICATION_REPLY)                    |
           |                                                 |
           |<-- PA-Server -----------------------------------|
           |     (Seq=1, Session ID=X, EAP request,          |
           |      rc=AUTHENTICATION_REQUEST)                 |

3.1.2.  Authentication Triggered by the Server

   In the scenario where a PCP server receives a common PCP request
   message from a PCP client that needs to be authenticated, the
   PCP server rejects the request with an AUTHENTICATION_REQUIRED error
   code and can reply with an unsolicited PA-Server message to initiate
   a PA session.  The Result Code field of this PA-Server message is set
   to AUTHENTICATION_REQUEST.  In addition, the PCP server MUST assign a
   Session ID for the session and transfer it within the PA-Server
   message.  The Sequence Number field in the PA-Server message is set
   to zero.  If the PCP client retries the common request before EAP
   authentication is successful, then it will receive an
   AUTHENTICATION_REQUIRED error code from the PCP server.  In
   subsequent PA messages exchanged during this session, the Session ID
   will be used in order to help session partners distinguish the
   messages within this session from those not within it.  When the
   PCP client receives this initial PA-Server message from the
   PCP server, it can reply with a PA-Client message or silently discard
   the request message, according to its local policies.  In the
   PA-Client message, a NONCE option that consists of a random nonce MAY
   be appended.  If so, in the next PA-Server message, the PCP server
   MUST forward the nonce back within a NONCE option.

Top      ToC       Page 8 
          PCP                                               PCP
         client                                            server
           |-- Common PCP request -------------------------->|
           |                                                 |
           |<- Common PCP response --------------------------|
           |    (rc=AUTHENTICATION_REQUIRED)                 |
           |                                                 |
           |<-- PA-Server -----------------------------------|
           |     (Seq=0, Session ID=X, EAP request,          |
           |      rc=AUTHENTICATION_REQUEST)                 |
           |                                                 |
           |-- PA-Client ----------------------------------->|
           |    (Seq=0, Session ID=X, EAP response,          |
           |     rc=AUTHENTICATION_REPLY)                    |
           |                                                 |
           |<-- PA-Server -----------------------------------|
           |     (Seq=1, Session ID=X, EAP request,          |
           |      rc=AUTHENTICATION_REQUEST)                 |

3.1.3.  Authentication Using EAP

   In a PA session, an EAP request message is transported within a
   PA-Server message and an EAP response message is transported within a
   PA-Client message.  EAP relies on the underlying protocol to provide
   reliable transmission; any reordered delivery or loss of packets
   occurring during transmission must be detected and addressed.
   Therefore, after sending out a PA-Server message, the PCP server will
   not send a new PA-Server message in the same PA session until it
   receives a PA-Client message with a proper sequence number from the
   PCP client, and vice versa.  If a PCP client receives a PA message
   containing an EAP request and for some reason cannot generate an EAP
   response immediately (e.g., waiting for human input in order to
   construct an EAP message, or waiting for the additional PA messages
   in order to assemble a complete EAP message from fragmented packets),
   the PCP device MUST reply with a PA-Acknowledgement message (a
   PA message with a RECEIVED_PAK option) to indicate that the message
   has been received.  This approach not only can avoid unnecessary
   retransmission of the PA message but also can guarantee reliable
   message delivery in conditions where a PCP device needs to receive
   multiple PA messages carrying the fragmented EAP request before
   generating an EAP response.  The number of EAP messages exchanged
   between the PCP client and PCP server depends on the EAP method used
   for authentication.

   In this approach, a PCP client and a PCP server MUST perform a
   key-generating EAP method in authentication.  Specifically, a PCP
   authentication implementation MUST support Extensible Authentication
   Protocol Tunneled Transport Layer Security (EAP-TTLS) [RFC5281] and

Top      ToC       Page 9 
   SHOULD support the Tunnel Extensible Authentication Protocol (TEAP)
   [RFC7170].  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 transport key using the MSK, they
   need to agree upon a Pseudorandom Function (PRF) for the transport
   key derivation and a Message Authentication Code (MAC) algorithm to
   provide data origin authentication for subsequent PCP messages.  In
   order to do this, the PCP server needs to append a set of PRF options
   and MAC_ALGORITHM options to the initial PA-Server message.  Each PRF
   option contains a PRF that the PCP server supports, and each
   MAC_ALGORITHM option contains a MAC algorithm that the PCP server
   supports.  Moreover, in the first PA-Server message, the server MAY
   also attach an ID_INDICATOR option (defined in Section 5.11) to
   direct the client to choose correct credentials.  After receiving the
   options, the PCP client MUST select the PRF and the MAC algorithm
   that it would like to use; it then MUST add the associated PRF and
   MAC Algorithm options to the next PA-Client message.

   After the EAP authentication, the PCP server sends out a PA-Server
   message to indicate the EAP authentication and PCP authorization
   results.  If the EAP authentication succeeds, the result code of the
   PA-Server message is AUTHENTICATION_SUCCEEDED.  In this case, before
   sending out the PA-Server message, the PCP server MUST update the
   PCP SA with the MSK and transport key and MUST use the derived
   transport key to generate a digest for the message.  The digest is
   transported within a PA_AUTHENTICATION_TAG option for PCP Auth.  A
   more detailed description of generating the authentication data can
   be found in Section 6.1.  In addition, the PA-Server message MUST
   also contain a SESSION_LIFETIME option (defined in Section 5.9) that
   indicates the lifetime of the PA session (i.e., the lifetime of the
   MSK).  After receiving the PA-Server message, the PCP client then
   needs to generate a PA-Client message in response.  If the PCP client
   also authenticates the PCP server, the result code of the PA-Client
   message is AUTHENTICATION_SUCCEEDED.  In addition, the PCP client
   needs to update the PCP SA with the MSK and transport key, and it
   uses the derived transport key to secure the message.  From then on,
   all the PCP messages within the session are secured with the
   transport key and the MAC algorithm specified in the PCP SA.  The
   first secure PA-Client message from the client MUST include the set
   of PRF and MAC_ALGORITHM options received from the PCP server.  The
   PCP server determines if the set of algorithms conveyed by the client
   matches the set it had initially sent, to detect an algorithm
   downgrade attack.  If the server detects a downgrade attack, then it
   MUST send a PA-Server message with result code
   DOWNGRADE_ATTACK_DETECTED and terminate the session.  If the
   PCP client sends a common PCP request within the PA session without
   an AUTHENTICATION_TAG option, then the PCP server rejects the request
   by returning an AUTHENTICATION_REQUIRED error code.

Top      ToC       Page 10 
   If a PCP client/server cannot authenticate its session partner, the
   device sends out a PA message with the result code
   AUTHENTICATION_FAILED.  If the EAP authentication succeeds but
   authorization fails, the device making the decision sends out a
   PA message with the result code AUTHORIZATION_FAILED.  In these two
   cases, after the PA message is sent out, the PA session MUST be
   terminated immediately.  It is possible for independent PCP clients
   on the host to create multiple PA sessions with the PCP server.

3.2.  Recovery from Lost PA Session

   If a PCP server resets or loses the PCP SA due to reboot, power
   failure, or any other reason, then it sends an unsolicited ANNOUNCE
   response, as explained in Section 14.1.3 of [RFC6887], to the
   PCP client.  Upon receiving the ANNOUNCE response with an anomalous
   Epoch Time, the PCP client deduces that the server may have lost
   state.  The ANNOUNCE is either bogus (an attack), legitimate, or not
   seen by the client.  These three cases are described below:

   o  The PCP client sends an integrity-protected unicast ANNOUNCE
      request to the PCP server to see whether the PCP server has indeed
      lost state or an attacker has sent the ANNOUNCE response.

      *  If an integrity-protected success response is received from the
         PCP server, then the PCP client determines that the PCP server
         has not lost the PA session, and the unsolicited ANNOUNCE
         response was sent by an attacker.

      *  If the PCP server responds to the ANNOUNCE request with an
         UNKNOWN_SESSION_ID error code, then the PCP client MUST
         initiate full EAP authentication with the PCP server, as
         explained in Section 3.1.1.  After EAP authentication is
         successful, the PCP client updates the PCP SA and issues new
         common PCP requests to recreate any lost mapping state.

   o  In a scenario where the PCP server has lost the PCP SA but did not
      inform the PCP client, if the PCP client sends an integrity-
      protected PCP request, then the PCP server rejects the request
      with an UNKNOWN_SESSION_ID error code.  The PCP client then
      initiates full EAP authentication with the PCP server, as
      explained in Section 3.1.1, and updates the PCP SA after
      successful authentication.

   If the PCP client resets or loses the PCP SA due to reboot, power
   failure, or any other reason and sends a common PCP request, then the
   PCP server rejects the request with an AUTHENTICATION_REQUIRED error
   code.  The PCP client MUST authenticate with the PCP server and,
   after EAP authentication is successful, retry the common PCP request

Top      ToC       Page 11 
   with an AUTHENTICATION_TAG option.  The PCP server MUST update the
   PCP SA after successful EAP authentication.

3.3.  Session Termination

   A PA session can be explicitly terminated by either session partner.
   A PCP server may explicitly request termination of the session by
   sending an unsolicited termination-indicating PA response (a
   PA response with a result code of SESSION_TERMINATED).  Upon
   receiving a termination-indicating message, the PCP client MUST
   respond with a termination-indicating PA message and MUST then remove
   the associated PCP SA.  To accommodate packet loss, the PCP server
   MAY transmit the termination-indicating PA response up to ten times
   (with an appropriate Epoch Time value in each to reflect the passage
   of time between transmissions), provided that (1) the interval
   between the first two notifications is at least 250 ms and (2) each
   interval between subsequent notifications at least doubles.

   A PCP client may explicitly request termination of the session by
   sending a termination-indicating PA request (a PA request with a
   result code of SESSION_TERMINATED).  After receiving a termination-
   indicating message from the PCP client, a PCP server MUST respond
   with a termination-indicating PA message and remove the PCP SA
   immediately.  When the PCP client receives the termination-indicating
   PA response, it MUST remove the associated PCP SA immediately.

3.4.  Session Re-authentication

   A session partner may choose to perform EAP re-authentication if it
   would like to update the PCP SA without initiating a new PA session.
   For example, a re-authentication procedure could be triggered for the
   following reasons:

   o  The session lifetime needs to be extended.

   o  The sequence number is going to reach the maximum value.
      Specifically, when the sequence number reaches 2**32 - 2**16, the
      session partner MUST trigger re-authentication.

   When the PCP server would like to initiate a re-authentication, it
   sends the PCP client a PA-Server message.  The result code of the
   message is set to RE-AUTHENTICATION, which indicates that the message
   is for a re-authentication process.  If the PCP client would like to
   start the re-authentication, it will send a PA-Client message to the
   PCP server, with the result code of the PA-Client message set to
   RE-AUTHENTICATION.  Then, the session partners exchange PA messages
   to transfer EAP messages for the re-authentication.  During the
   re-authentication procedure, the session partners protect the

Top      ToC       Page 12 
   integrity of PA messages with the key and MAC algorithm specified in
   the current PCP SA; the sequence numbers associated with the message
   will continue to keep increasing as specified in Section 6.4.  The
   result code for a PA-Server message carrying an EAP request will be
   set to AUTHENTICATION_REQUIRED, and a PA-Client message carrying an
   EAP response will be set to AUTHENTICATION_REPLY.

   If the EAP re-authentication succeeds, the result code of the last
   PA-Server message is AUTHENTICATION_SUCCEEDED.  In this case, before
   sending out the PA-Server message, the PCP server MUST update the SA
   and use the new key to generate a digest for the PA-Server message
   and subsequent PCP messages.  In addition, the PA-Server message MUST
   be appended with a SESSION_LIFETIME option that indicates the new
   lifetime of the PA session.  PA and PCP message sequence numbers must
   also be reset to zero.

   If the EAP authentication fails, the result code of the last
   PA-Server message is AUTHENTICATION_FAILED.  If the EAP
   authentication succeeds but authorization fails, the result code of
   the last PA-Server message is AUTHORIZATION_FAILED.  In the latter
   two cases, the PA session MUST be terminated immediately after the
   last PA message exchange.  If for some unknown reason
   re-authentication is not performed and the session lifetime has
   expired, then the PA session MUST be terminated immediately.

   During re-authentication, the session partners can also exchange
   common PCP messages in parallel.  The common PCP messages MUST be
   protected with the current SA until the new SA has been generated.
   The sequence of EAP messages exchanged for re-authentication will not
   change, regardless of the PCP device triggering re-authentication.
   If the PCP server receives a re-authentication request from the
   PCP client after the PCP server itself had sent a re-authentication
   request, then it should discard its request and respond to the
   re-authentication request from the PCP client.

4.  PA Security Association

   At the beginning of a new PA session, each PCP device must create and
   initialize state information for a new PA Security Association
   (PCP SA) to maintain its state information for the duration of the
   PA session.  The parameters of a PCP SA are 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.

Top      ToC       Page 13 
   o  Sequence number for the next outgoing PA message.

   o  Sequence number for the next incoming PA message.

   o  Sequence number for the next outgoing common PCP message.

   o  Sequence number for the next incoming common PCP message.

   o  Last outgoing message payload.

   o  Retransmission interval.

   o  The Master Session Key (MSK) generated by the EAP method.

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

   o  The pseudorandom function negotiated in the initial PA-Server and
      PA-Client message exchange for the transport key derivation.

   o  The transport key derived from the MSK to provide integrity
      protection and data origin authentication for the messages in the
      PA session.  The lifetime of the transport key SHOULD be identical
      to the lifetime of the session.

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

   o  The key ID associated with the transport key.

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

   o  prf is the pseudorandom function assigned in the PRF option
      (Section 5.7).

   o  MSK is the master session key generated by the EAP method.

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

   o  '||' is the concatenation operator.

   o  Session ID is the ID of the session from which the MSK is derived.

Top      ToC       Page 14 
   o  Nonce is the nonce selected by the client and transported in the
      initial PA-Client message.

   o  Key ID is the ID assigned for the transport key.

5.  Packet Format

5.1.  Packet Format of PCP Auth Messages

   The format of the PA-Server message is identical to the response
   message format specified in Section 7.2 of [RFC6887].  The result
   code for a PA-Server message carrying an EAP request MUST be set to
   AUTHENTICATION_REQUEST.

   This document updates the Reserved field (see Figure 1) in the
   Request header specified in Section 7.1 of [RFC6887] to carry
   Opcode-specific data.

      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    |Opcode-specific|
     |               | |             |               |   data        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Requested Lifetime (32 bits)                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |            PCP Client's IP Address (128 bits)                 |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :                  Opcode-specific information                  :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :                   (optional) PCP Options                      :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 1: Request Packet Format

Top      ToC       Page 15 
   The PA-Client messages (as shown in Figure 2) use the Request header
   specified in Figure 1.  The Opcode-specific data is used to transfer
   the result codes (e.g., INITIATION, AUTHENTICATION_FAILED).  Other
   fields in Figure 2 are described in Section 7.1 of [RFC6887].  The
   result code for a PA-Client message carrying an EAP response MUST be
   set to AUTHENTICATION_REPLY.

      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)                 |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :                  Opcode-specific information                  :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :                   (optional) PCP Options                      :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 2: PA-Client Message Format

   The Requested Lifetime field of a PA-Client message and the Lifetime
   field of a PA-Server message are both set to zero on transmission and
   ignored on reception.

Top      ToC       Page 16 
5.2.  Opcode-Specific Information of AUTHENTICATION Opcode

   The following diagram shows the format of the Opcode-specific
   information for the 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 PA session identifier.

      Sequence Number: This field contains a 32-bit sequence number.  A
      sequence number needs to be incremented on every new
      (non-retransmission) outgoing PA message in order to provide an
      ordering guarantee for PA messages.

5.3.  NONCE Option

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

       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 Code: 4.

      Reserved: 8 bits.  MUST be set to zero on transmission and MUST be
      ignored on reception.

      Option-Length: 4 octets.

Top      ToC       Page 17 
      Nonce: A random 32-bit number that is transported within a
      PA-Initiation message and the corresponding reply message from the
      PCP server.

5.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                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Sequence Number                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Key ID                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                Authentication Data (Variable)                 |
      ~                                                               ~
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Because there is no authentication Opcode in common PCP messages, the
   authentication tag for common PCP messages needs to carry the
   Session ID and Sequence Number.

      Option Code: 5.

      Reserved: 8 bits.  MUST be set to zero on transmission and MUST be
      ignored on reception.

      Option-Length: The length of the AUTHENTICATION_TAG option for the
      common PCP message (in octets), including the 12-octet
      fixed-length header and the variable-length authentication data.

      Session ID: A 32-bit field used to identify the session to which
      the message belongs and identify the secret key used to create the
      message digest appended to the PCP message.

      Sequence Number: A 32-bit sequence number.  In this option, a
      sequence number needs to be incremented on every new
      (non-retransmission) outgoing common PCP message in order to
      provide an ordering guarantee for common PCP messages.

Top      ToC       Page 18 
      Key ID: The ID associated with the transport key used to generate
      authentication data.  This field is filled with zeros if the MSK
      is directly used to secure the message.

      Authentication Data: A variable-length field that carries the
      Message Authentication Code for the common PCP message.  The
      generation of the digest varies according to the algorithms
      specified in different PCP SAs.  This field MUST end on a 32-bit
      boundary, padded with zeros when necessary.

5.5.  PA_AUTHENTICATION_TAG Option

   This option is used to provide message authentication for
   PA messages.  In contrast to the AUTHENTICATION_TAG option for common
   PCP messages, the Session ID field and the Sequence Number field are
   removed because such information is provided in the Opcode-specific
   information of the 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Option Code  |  Reserved     |       Option-Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Key ID                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                Authentication Data (Variable)                 |
      ~                                                               ~
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Option Code: 6.

      Reserved: 8 bits.  MUST be set to zero on transmission and MUST be
      ignored on reception.

      Option-Length: The length of the PA_AUTHENTICATION option for the
      PCP Auth message (in octets), including the 4-octet fixed-length
      header and the variable-length authentication data.

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

      Authentication Data: A variable-length field that carries the
      Message Authentication Code for the PCP Auth message.  The
      generation of the digest varies according to the algorithms

Top      ToC       Page 19 
      specified in different PCP SAs.  This field MUST end on a 32-bit
      boundary, padded with null characters when necessary.

5.6.  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 Code: 7.

      Reserved: 8 bits.  MUST be set to zero on transmission and MUST be
      ignored on reception.

      Option-Length: Variable.

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

5.7.  PRF 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           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          PRF                                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Option Code: 8.

      Reserved: 8 bits.  MUST be set to zero on transmission and MUST be
      ignored on reception.

      Option-Length: 4 octets.

      PRF: The pseudorandom function that the sender supports to
      generate an MSK.  This field contains a value indicating Internet
      Key Exchange Protocol version 2 (IKEv2) Transform Type 2 [RFC7296]
      [RFC4868].  A PCP implementation MUST support PRF_HMAC_SHA2_256
      (transform ID = 5).

Top      ToC       Page 20 
5.8.  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                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Option Code: 9.

      Reserved: 8 bits.  MUST be set to zero on transmission and MUST be
      ignored on reception.

      Option-Length: 4 octets.

      MAC Algorithm ID: Indicates the MAC algorithm that the sender
      supports to generate authentication data.  The MAC Algorithm ID
      field contains a value indicating IKEv2 Transform Type 3 [RFC7296]
      [RFC4868].  A PCP implementation MUST support
      AUTH_HMAC_SHA2_256_128 (transform ID = 12).

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

      Option Code: 10.

      Reserved: 8 bits.  MUST be set to zero on transmission and MUST be
      ignored on reception.

      Option-Length: 4 octets.

      Session Lifetime: An unsigned 32-bit integer, in seconds, ranging
      from 0 to 2^32-1 seconds.  The lifetime of the PA session, which
      is decided by the authorization result.

Top      ToC       Page 21 
5.10.  RECEIVED_PAK Option

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

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

      Option Code: 11.

      Reserved: 8 bits.  MUST be set to zero on transmission and MUST be
      ignored on reception.

      Option-Length: 4 octets.

      Received Sequence Number: The sequence number of the last received
      PA message.

5.11.  ID_INDICATOR Option

   The ID_INDICATOR option is used by the PCP client to determine which
   credentials to provide to the PCP server.

       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           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                          ID Indicator                         |
      ~                                                               ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Option Code: 12.

      Reserved: 8 bits.  MUST be set to zero on transmission and MUST be
      ignored on reception.

      Option-Length: Variable.

      ID Indicator: The identity of the authority that issued the EAP
      credentials to be used to authenticate the client.  The field

Top      ToC       Page 22 
      MUST NOT be null terminated, and its length is indicated by the
      Option-Length field.  In particular, when a client receives an
      ID_INDICATOR option, it MUST NOT rely on the presence of a null
      character in the wire format data to identify the end of the
      ID Indicator field.

      The field MUST end on a 32-bit boundary, padded with zeros when
      necessary.  The ID Indicator field is a UTF-8 encoded [RFC3629]
      Unicode string conforming to the UsernameCaseMapped profile of the
      PRECIS IdentifierClass [RFC7613].  The PCP client validates that
      the ID Indicator field conforms to the UsernameCaseMapped profile
      of the PRECIS IdentifierClass.  The PCP client enforces the rules
      specified in Section 3.2.2 of [RFC7613] to map the ID Indicator
      field.  The PCP client compares the resulting string with the ID
      indicators stored locally on the PCP client to pick the
      credentials for authentication.  The two indicator strings are to
      be considered equivalent by the client if and only if they are an
      exact octet-for-octet match.



(page 22 continued on part 2)

Next RFC Part