wdiff rfc7652.original rfc7652.txt

Network Working Group
Internet Engineering Task Force (IETF) M. Wasserman
Internet-Draft Cullen
Request for Comments: 7652 S. Hartman
Updates: 6887 (if approved) Painless Security
Intended status:
Category: Standards Track D. Zhang
Expires: January 21, 2016 Huawei
ISSN: 2070-1721
T. Reddy
Cisco
July 20,
September 2015

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

Abstract

An IPv4 or IPv6 host can use the Port Control Protocol (PCP) to
flexibly manage the IP address address-mapping and port mapping port-mapping information
on Network Address Translators (NATs) or firewalls to facilitate
communication with remote hosts. However, the un-controlled uncontrolled
generation or deletion of IP address mappings on such network devices
may cause security risks and should be avoided. In some cases cases, the
client may need to prove that it is authorized to modify, create 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 RFC6887. RFC 6887.

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 an Internet Standards Track document.

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

Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for a maximum 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 six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 21, 2016.
http://www.rfc-editor.org/info/rfc7652.

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

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 5
3.1.1. Authentication triggered Triggered by the client Client . . . . . . . 6 5
3.1.2. Authentication triggered Triggered by the server Server . . . . . . . 7 6
3.1.3. Authentication using Using EAP . . . . . . . . . . . . . . 7
3.2. Recovery from lost Lost PA session Session . . . . . . . . . . . . . . 9
3.3. Session Termination . . . . . . . . . . . . . . . . . . . 10
3.4. Session Re-Authentication Re-authentication . . . . . . . . . . . . . . . . 11 10
4. PA Security Association . . . . . . . . . . . . . . . . . . . 12
5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Packet Format of PCP Auth Messages . . . . . . . . . . . 13
5.2. Opcode-specific information Opcode-Specific Information of AUTHENTICATION Opcode . . 15
5.3. NONCE Option . . . . . . . . . . . . . . . . . . . . . . 16
5.4. AUTHENTICATION_TAG Option . . . . . . . . . . . . . . . . 16
5.5. PA_AUTHENTICATION_TAG option 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 . . . . . . . . . 24
6.5. Sequence Numbers for Common PCP Messages . . . . . . . . 25
6.6. MTU Considerations . . . . . . . . . . . . . . . . . . . 26
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
7.1. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.2. AUTHENTICATION_TAG . . . . . . . . . . . . . . . . . . . 28
7.3. PA_AUTHENTICATION_TAG . . . . . . . . . . . . . . . . . . 28
7.4. EAP_PAYLOAD . . . . . . . . . . . . . . . . . . . . . . . 29
7.5. PRF . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.6. MAC_ALGORITHM . . . . . . . . . . . . . . . . . . . . . . 29
7.7. SESSION_LIFETIME . . . . . . . . . . . . . . . . . . . . 30
7.8. RECEIVED_PAK . . . . . . . . . . . . . . . . . . . . . . 30
7.9. ID_INDICATOR . . . . . . . . . . . . . . . . . . . . . . 30
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.1. Changes from wasserman-pcp-authentication-02 to ietf-
pcp-authentication-00 . . . . . . . . . . . . . . . . . 32
10.2. Changes from wasserman-pcp-authentication-01 to -02 . . 32
10.3. Changes from ietf-pcp-authentication-00 to -01 . . . . . 32
10.4. Changes from ietf-pcp-authentication-01 to -02 References . . . . . 32
10.5. Changes from ietf-pcp-authentication-02 to -03 . . . . . 33
10.6. Changes from ietf-pcp-authentication-03 to -04 . . . . . 33
10.7. Changes from ietf-pcp-authentication-04 to -05 . . . . . 33
10.8. Changes from ietf-pcp-authentication-05 to -06 . . . . . 33
11. 31
9.1. Normative References . . . . . . . . . . . . . . . . . . 31
9.2. Informative References . . . . . . . 34
11.1. Normative References . . . . . . . . . . . 33
Acknowledgements . . . . . . . 34
11.2. Informative References . . . . . . . . . . . . . . . . . 35 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 33

1. Introduction

Using the Port Control Protocol (PCP) [RFC6887], an application can
flexibly manage the IP address mapping address-mapping information on its network
address translators (NATs) and firewalls, 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 un-authorized 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 transportation. transmission.

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

o Loss of EAP messages during transportation transmission.

o Reordered delivery of EAP messages messages.

o Generation of transport keys keys.

o Integrity protection and data origin authentication for
PCP
messages messages.

o Algorithm agility 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 do does not create implicit mappings for specific traffic.

o On equipment (such as CGNs Carrier-Grade NATs (CGNs) or service
provider firewalls) that
serve 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.

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

PCP Server: server: A PCP software instance that resides on the PCP-
Controlled Device
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: session: A series of PCP message exchanges
transferred between a PCP client and a PCP server. The PCP messages
involved within
that are part of a given session includes include the PA messages used to
perform EAP authentication, key distribution distribution, and session management, and
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: partner: A PCP implementation involved within 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: lifetime: The lifetime associated with a PA session, which session. The
session lifetime of the PA session decides the lifetime of the
current authorization given to the PCP client.

PCP

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

PCP-Authentication (PA) message: A PCP message containing an
AUTHENTICATION Opcode. Particularly, 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, option -- the PA_AUTHENTICATION_TAG Option option defined in Section 5.5
for PCP
authentication, authentication -- to provide integrity protection and message
origin authentication for PA messages.

Common PCP message: A PCP message which that does not contain an
AUTHENTICATION Opcode. This document specifies an AUTHENTICATION_TAG
Option
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 options for
various purposes (e.g., transporting authentication messages and
session management). The opcode-specific Opcode-specific information in a an
AUTHENTICATION Opcode consists of two fields : 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 Sequence Number field is used to
detect whether reordering or duplication occurred during message
delivery.

3.1.1. Authentication triggered Triggered by the client 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") INITIATION) to the PCP server. Section 5.1
updates the PCP request message format with result codes for the PCP
Authentication
authentication mechanism. In the opcode-specific Opcode-specific information of the
message, the Session ID and Sequence Number fields are set as 0. to zero.

The PA-Client message MUST also contain a NONCE option defined (defined in
Section 5.3 which 5.3) that consists of a random nonce.

After receiving the PA-Initiation, PA-Initiation message, if the PCP server agrees
to initiate a PA session with the PCP client, it will reply with a PA-
Server
PA-Server message which that contains an EAP Request request, and the result code Result Code
field of this PA-Server message is set to AUTHENTICATION_REQUEST. In
addition, the server MUST assign a unique session identifier to
distinctly identify this session, session and fill insert the identifier into the
Session ID field in the opcode-specific Opcode-specific information of the PA-Server
message. The Sequence Number field of the message is set as 0. 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-------------------------------->| 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 Triggered by the server Server

In the scenario where a PCP server receives a common PCP request
message from a PCP client which that needs to be authenticated, the
PCP server rejects the request with a an AUTHENTICATION_REQUIRED error
code and can reply with a an unsolicited PA-Server message to initiate
a PA session. The result code 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
as 0.
to zero. If the PCP client retries the common request before EAP
authentication is successful successful, then it will receive an
AUTHENTICATION_REQUIRED error code from the PCP server. In the
subsequent PA messages exchanged afterwards in 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. 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 message, according to its local policies. In the
PA-Client message, a NONCE option which 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.

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

3.1.3. Authentication using Using EAP

In a PA session, an EAP request message is transported within a PA-
Server
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 transportation 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 due to certain reasons (e.g., waiting for human input in order to
construct a an EAP message message, or due to EAP message fragmentation waiting for the additional PA messages
in order to construct assemble a complete EAP
message), message from fragmented packets),
the PCP device MUST reply with a PA-Acknowledgement message
(PA (a
PA message with a RECEIVED_PAK Option) 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 the 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
key-generating EAP method in authentication. Particularly, Specifically, a PCP
authentication implementation MUST support EAP-TTLS Extensible Authentication
Protocol Tunneled Transport Layer Security (EAP-TTLS) [RFC5281] and
SHOULD support TEAP 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 Pseudo-Random Pseudorandom Function (PRF) for the transport
key derivation and a MAC 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 options
and MAC_ALGORITHM Options options to the initial PA-Server message. Each PRF Option
option contains a PRF that the PCP server supports, and each
MAC_ALGORITHM Option option contains a MAC (Message Authentication Code) algorithm that the PCP server
supports. Moreover, in the first PA-
Server PA-Server message, the server MAY
also attach an ID_INDICATOR Option
defined option (defined in Section 5.11 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 which
that it would like to use, and use; it then
adds MUST add the associated PRF and
MAC Algorithm Options options to the next PA-
Client 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, key and MUST use the derived
transport key to generate a digest for the message. The digest is
transported within an a PA_AUTHENTICATION_TAG Option 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 option (defined in Section 5.9 which 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 as 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 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 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 option, then the PCP server rejects the request
by returning an AUTHENTICATION_REQUIRED error code.

If a PCP client/server cannot authenticate its session partner, the
device sends out a PA message with the result code, 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, 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 Lost PA session Session

If a PCP server resets or loses the PCP SA due to reboot, power
failure, or any reason other reason, then it sends an unsolicited ANNOUNCE response
response, as explained in section Section 14.1.3 of [RFC6887] [RFC6887], to the
PCP client. Upon receiving the ANNOUNCE response with an anomalous
Epoch time, 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 check if see whether the PCP server has indeed
lost the state or an attacker has sent the ANNOUNCE response.

* If an integrity-protected success response is recevied received from the
PCP server 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 code, then the PCP client MUST
initiate full EAP authentication with the PCP server server, as
explained in Section 3.1.1. After EAP authentication is successful
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
integrity-protected 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 server, as
explained in Section 3.1.1 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 request, then the
PCP server rejects the request with an AUTHENTICATION_REQUIRED error
code. The PCP client MUST authenticate with the PCP server and and,
after EAP authentication is successful successful, retry the common PCP request
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 server may explicitly request termination of the session by
sending an unsolicited termination-indicating PA response (a
PA response with a result code "SESSION-TERMINATED"). of SESSION_TERMINATED). Upon
receiving a termination-indicating message, the PCP client MUST
respond with a termination-indicating PA message, 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) transmissions), provided that (1) the interval
between the first two notifications is at least 250 ms, ms and the (2) each
interval between subsequent notification 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 "SESSION-TERMINATED"). of SESSION_TERMINATED). After receiving a termination-
indicating message from the PCP client, a PCP server MUST respond
with a termination-indicating PA response 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 Re-authentication

A session partner may select choose to perform EAP re-authentication if it
would like to update the PCP SA without initiating a new PA session.
For example 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", 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".
RE-AUTHENTICATION. Then, the session partners exchange PA messages
to transfer EAP messages for the re-authentication. During the re-
authentication
re-authentication procedure, the session partners protect the
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 according to as specified in Section 6.3. 6.4. The
result code for PA-Sever a PA-Server message carrying an EAP request will be
set to
AUTHENTICATION_REQUIRED 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". 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 which 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
PA-Server message is "AUTHENTICATION_FAILED". AUTHENTICATION_FAILED. If the EAP
authentication succeeds but authorization fails, the result code of
the last PA-
Server PA-Server message is "AUTHORIZATION_FAILED". 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
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 it the PCP server itself had signaled sent a re-authentication request
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 listed as follows:

o IP address and UDP port number of the PCP client client.

o IP address and UDP port number of the PCP server server.

o Session Identifier identifier.

o Sequence number for the next outgoing PA message message.

o Sequence number for the next incoming PA message message.

o Sequence number for the next outgoing common PCP message message.

o Sequence number for the next incoming common PCP message message.

o Last outgoing message payload payload.

o Retransmission interval interval.

o The master session key 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 pseudo random pseudorandom function negotiated in the initial PA-Server and
PA-Client message exchange for the transport key derivation 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 key ID associated with Transport the transport key.

Particularly,

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

o prf: The pseudo-random prf is the pseudorandom function assigned in the Pseudo-random
function parameter. PRF option
(Section 5.7).

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

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

o '||' : is the concatenation operator.

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

o Nonce: The Nonce is the nonce selected by the client and transported in the
Initial
initial PA-Client message.

o Key ID: The 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 PA-Sever a PA-Server message carrying an EAP request MUST be set to
AUTHENTICATION_REQUEST.

As illustrated in Figure 1, this

This document updates the reserved Reserved field (see Figure 1) in the request
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. 1: Request Packet Format

As illustrated in Figure 2, the

The PA-Client messages (as shown in Figure 2) use the request Request header
specified in Figure 1. The Opcode-specific data is used to transfer
the result codes (e.g., "INITIATION",
"AUTHENTICATION_FAILED"). 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. 2: PA-Client message Message Format

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

5.2. Opcode-specific information 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)
(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 which 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 off-line generated 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 discarded silently. 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: TBA-130. 4.

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

Option-Length: 4 octets.

Nonce: A random 32 bit 32-bit number which that is transported within a PA-
Initiation
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: TBA-131. 5.

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

Option-Length: The length of the AUTHENTICATION_TAG Option option for
Common the
common PCP message (in octets), including the 12 octet fixed 12-octet
fixed-length header and the variable length of 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 solution, option, a
sequence number needs to be incremented on every new (non-
retransmission)
(non-retransmission) outgoing common PCP message in order to
provide an ordering guarantee for common PCP messages.

Key ID: The ID associated with the transport key used to generate
authentication data. This field is filled with zero 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 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 0's zeros when necessary.

5.5. PA_AUTHENTICATION_TAG option Option

This option is used to provide message authentication for
PA messages. Compared with In contrast to the AUTHENTICATION_TAG Option option for Common common
PCP
Messages, 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: TBA-132. 6.

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

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

Key ID: The ID associated with the transport key used to generate
authentication data. This field is filled with zero 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
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: TBA-133. 7.

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

Option-Length: Variable Variable.

EAP Message: The EAP message transferred. Note that this field
MUST end on a 32-bit boundary, padded with 0's 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: TBA-134. 8.

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

Option-Length: 4 octets.

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

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: TBA-135. 9.

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

Option-Length: 4 octets.

MAC Algorithm ID: Indicate Indicates the MAC algorithm which that the sender
supports to generate authentication data. The MAC Algorithm ID
field contains an a value indicating IKEv2 Transform ID of Transform Type 3
[RFC7296][RFC4868]. [RFC7296]
[RFC4868]. A PCP implementation MUST support
AUTH_HMAC_SHA2_256_128 (12). (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: TBA-136. 10.

Reserved: 8 bits. MUST be set to 0 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, session, which
is decided by the authorization result.

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: TBA-137. 11.

Reserved: 8 bits. MUST be set to 0 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: TBA-138. 12.

Reserved: 8 bits. MUST be set to 0 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
MUST NOT be null terminated terminated, and its length is indicated by the Option-
Length
Option-Length field. In particular particular, when a client receives a an
ID_INDICATOR option, it MUST NOT rely on the presence of a NUL 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 0's zeros when
necessary. The ID indicator Indicator field is a UTF-8 encoded [RFC3629]
Unicode string conforming to the "UsernameCaseMapped" UsernameCaseMapped profile of the
PRECIS IdentifierClass [I-D.ietf-precis-saslprepbis]. [RFC7613]. The PCP client validates that
the ID indicator Indicator field conforms to the
"UsernameCaseMapped" UsernameCaseMapped profile
of the PRECIS IdentifierClass. The PCP client enforces the rules
specified in section Section 3.2.2 of
[I-D.ietf-precis-saslprepbis] [RFC7613] to map the ID indicator 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 octet-for-octet match.

6. Processing Rules

6.1. Authentication Data Generation

After a successful EAP authentication process, every subsequent
PCP message within the PA session MUST carry an authentication tag which
that contains the digest of the PCP message for data origin
authentication and integrity protection.

o Before generating a digest for a PA message, a device needs to
first locate the PCP SA according to the session identifier and
then get the transport key. Then Then, the device appends an a
PA_AUTHENTICATION_TAG Option option for PCP Auth at the end of the
PCP Auth message. The length of the Authentication Data field is
decided by the MAC algorithm adopted in the session. The device
then fills the Key ID field with the key ID of the transport key, key
and sets the Authentication Data field to 0. zero. After this, the
device generates a digest for the entire PCP message (including
the PCP header and PA_AUTHENTICATION_TAG Option) option) using the
transport key and the associated MAC algorithm, and inserts the
generated digest into the Authentication Data field.

o Similar to generating a digest for a PA message, before generating
a digest for a common PCP message, a device needs to first locate
the PCP SA according to the session identifier and then get the
transport key. Then Then, the device appends the AUTHENTICATION_TAG
Option
option at the end of the common PCP message. The length of the
Authentication Data field is decided by the MAC algorithm adopted
in the session. The device then uses the corresponding values
derived from the SA to fill the Session ID field, the Sequence
Number field field, and the Key ID field, and sets the Authentication
Data field to 0. zero. After this, the device generates a digest for
the entire PCP message (including the PCP header and
AUTHENTICATION_TAG Option) option) using the transport key and the
associated MAC algorithm, and inputs inserts the generated digest into
the Authentication Data field.

6.2. Authentication Data Validation

When a device receives a common PCP message with an
AUTHENTICATION_TAG Option option for Common common PCP Messages, messages, the device needs
to use the Session ID transported in the option to locate the proper
SA,
SA and then find the associated transport key (using the key ID in
the option) and the MAC algorithm. If no proper SA or transport key
is found or the sequence number is invalid (see Section 6.5), the PCP
device stops processing the PCP message and silently discards the message
silently.
message. After storing the value of the Authentication field of the
AUTHENTICATION_TAG Option, option, the device fills the Authentication field
with zeros. Then, the device generates a digest for the message
(including the PCP header and Authentication Tag Option) AUTHENTICATION_TAG option) with the
transport key and the MAC algorithm. If the value of the newly
generated digest is identical to the stored one, the device can
ensure that the message has not been tampered with, and the
validation succeeds. Otherwise, the PCP device stops processing the
PCP message and silently discards the message.

Similarly, when a device receives a PA message with an a
PA_AUTHENTICATION_TAG Option option for PCP Authentication, authentication, the device needs
to use the Session ID transported in the Opcode to locate the proper
SA,
SA and then find the associated transport key (using the key ID in
the option) and the MAC algorithm. If no proper SA or transport key
is found or the sequence number is invalid (see Section 6.4), the PCP
device stops processing the PCP message and silently discards the
message. After storing the value of the Authentication field of the
PA_AUTHENTICATION_TAG Option, option, the device fills the Authentication
field with zeros. Then, the device generates a digest for the
message (including the PCP header and PA_AUTHENTICATION_TAG Option) option)
with the transport key and the MAC algorithm. If the value of the
newly generated digest is identical to the stored one, the device can
ensure that the message has not been tampered with, and the
validation succeeds. Otherwise, the PCP device stops processing the
PCP message and silently discards the message.

6.3. Retransmission Policies for PA Messages

Because EAP relies on the underlying protocols to provide reliable
transmission, after sending a PA message, a PCP client/server
MUST NOT send out any subsequent messages until receiving it has received a
PA message with a proper sequence number from the peer. If no such a
message is
received received, the PCP device will re-send resend the last message
according to retransmission policies. This work reuses specification uses the
retransmission policies specified in the base PCP protocol (Section Section 8.1.1 of
[RFC6887]). In the base PCP protocol,
specification [RFC6887]. In base PCP, such retransmission policies
are only applied by PCP clients. However, in this work, specification,
such retransmission policies are also applied by the PCP servers. If
Maximum retransmission
the "maximum retransmission" duration seconds have (in seconds) has elapsed and no
expected response is received, the device will terminate the session
and discard the current SA.

As illustrated discussed in Section 3.1.3, in order to avoid unnecessary re-
transmission,
retransmission, the device receiving a PA message MUST send a PA-
Acknowledgement
PA-Acknowledgement message to the sender of the PA message when it
cannot send a PA response immediately. The PA-Acknowledgement
message is used to indicate the receipt of the PA message. When the
sender receives the PA-Acknowledgement message, it will stop the
retransmission.

Note that the last PA messages transported within the phases of
session initiation, session re-authentication, and session
termination do not have to follow the above policies policies, since the
devices sending out those messages do not expect any further
PA messages.

When a device receives a re-transmitted retransmitted last incoming PA message from
its session partner, it MUST try to answer it by sending the last
outgoing PA message again. However, if the duplicate message has the
same sequence number but is not bit-wise bitwise identical to the original
message
message, then the device MUST discard it. In order to achieve perform this
function, the device may need to maintain the last incoming message
and the associated outgoing messages. In this case, if no outgoing
PA message has been generated for the received duplicate PA message
yet, the device needs to send a PA-Acknowledgement message. The rate
of replying to duplicate PA messages MUST be limited to provide
robustness against denial of service denial-of-service (DoS) attacks. The details of
rate limiting are outside the scope of this specification.

6.4. Sequence Numbers for PCP Auth Messages

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

The above rules are not applicable to PA-Acknowledgement messages
(i.e., PA messages containing a RECEIVED_PAK Option). option). A PA-
Acknowledgement
PA-Acknowledgement message does not transport any EAP message and
only indicates that a PA message is received. Therefore, reliable
transmission of PA-Acknowledgement messages is not required. For
instance, after sending out a PA-Acknowledgement message, a device
generates an EAP response. In this case, the device need does not have to
confirm whether the PA-Acknowledgement message has been received by
its session partner or not. Therefore, when receiving or sending out
a PA-Acknowledgement message, the device MUST NOT increase the
corresponding sequence number stored in the SA. Otherwise, loss of a
PA-Acknowledgement message will cause a mismatch in sequence numbers.

Another exception is the message retransmission scenario. As
discussed in Section 6.3, when a PCP device does not receive any
response from its session partner partner, it needs to retransmit the last
outgoing PA message message, following the retransmission procedure specified
in section Section 8.1.1 of [RFC6887]. The original message and duplicate
messages MUST be bit-wise bitwise identical. When the device receives such a
duplicate PA message from its session partner, it MUST send the last
outgoing PA message again. In such cases, the maintained incoming
and outgoing sequence numbers will not be affected by the message
retransmission.

6.5. Sequence Numbers for Common PCP Messages

When transporting common PCP messages within a PA session, a PCP
device needs to maintain a sequence number for outgoing common
PCP messages and a sequence number for incoming common PCP messages.
When generating a new outgoing PCP message, the PCP device updates
the Sequence Number field in the AUTHENTICATION_TAG option with the
outgoing sequence number maintained in the SA and increments the
outgoing sequence number by 1.

When receiving a PCP message from its session partner, the PCP device
will not accept it if the sequence number carried in the message is
smaller than the incoming sequence number maintained in the device maintains. device.
This approach can protect the PCP device from replay attacks. After
confirming that the received message is valid, the PCP device will
update the incoming sequence number maintained in the PCP SA with the
sequence number of the incoming message.

Note that the sequence number in the incoming message may not exactly
match the incoming sequence number maintained locally. As discussed
in the base PCP specification [RFC6887], if a PCP client is no longer
interested in the PCP transaction and has not yet received a
PCP response from the server server, then it will stop retransmitting the
PCP request. After that, the PCP client might generate new
PCP requests for other purposes purposes, using the current SA. In this case,
the sequence number in the new request will be larger than the
sequence number in the old request and so will be larger than the
incoming sequence number maintained in the PCP server.

Note that that, as discussed in the base PCP specification [RFC6887], a
PCP client needs to select a nonce in each MAP or PEER request, and
the nonce is sent back in the response. However, it is possible for
a client to use the same nonce in multiple MAP or PEER requests, and
this may cause a potential risk of replay attacks. This attack is
addressed by using the sequence number in the PCP response.

6.6. MTU Considerations

EAP methods are responsible for MTU handling, so no special
facilities are required in PCP to deal with MTU issues.
Particularly,
Specifically, EAP lower layers indicate to EAP methods and AAA
Authentication, Authorization, and Accounting (AAA) servers the MTU
of the lower layer. EAP methods such as EAP-TLS [RFC5216], TEAP
[RFC7170], and others that are likely to exceed reasonable MTUs
provide support for fragmentation and reassembly. Others, such as EAP-GPSK [RFC5433]
EAP - Generalized Pre-Shared Key (EAP-GPSK) [RFC5433], assume that
they will never send packets larger than the MTU and use small EAP
packets.

If an EAP message is too long to be transported within a single
PA message, it will be divided into multiple sections and sent within
different PA messages. Note that the receiver may not be able to
know what to do in the next step until it has received all the
sections and reconstructed the complete EAP message. In this case,
in order to guarantee reliable message transmission, after receiving
a PA message, the receiver replies with a PA-Acknowledgement message
to notify the sender to send the next PA message.

7. IANA Considerations

The following PCP Opcode is to be has been allocated in the mandatory-to-
process range from the standards action Standards Action
range (the of the "PCP Opcodes" registry for PCP
Opcodes (which is maintained in http://www.iana.org/assignments/pcp-
parameters):

TBA AUTHENTICATION Opcode.
<http://www.iana.org/assignments/pcp-parameters>):

3 AUTHENTICATION.

The following PCP result codes are to be have been allocated in the mandatory-
to-process range from the standards action Standards
Action range (the of the "PCP Result Codes" registry for
PCP result codes (which is maintained
in http://www.iana.org/assignments/
pcp-parameters):

TBA <http://www.iana.org/assignments/pcp-parameters>):

14 INITIATION: The client indication includes this PCP result code in its
request to the server for authentication.

TBA

15 AUTHENTICATION_REQUIRED: The This error response is signaled sent to the
client that if EAP authentication is required.

TBA

16 AUTHENTICATION_FAILED: This error response is signaled sent to the
client if EAP authentication had failed.

TBA AUTHENTICATION_SUCCEEDED:This

17 AUTHENTICATION_SUCCEEDED: This success response is signaled sent to the
client if EAP authentication had succeeded.

TBA

18 AUTHORIZATION_FAILED: This error response is signaled sent to the client
if the EAP authentication had succeeded but authorization failed.

TBA

19 SESSION_TERMINATED: This PCP result code indicates to the
partner that the PA session must be terminated.

TBA

20 UNKNOWN_SESSION_ID: The This error response is signaled sent from the
PCP server that if there is no known PA session associated with the
Session ID signaled sent in the PA request or common PCP request from the
PCP client.

TBA

21 DOWNGRADE_ATTACK_DETECTED: This error response is signaled PCP result code indicates to
the client if that the server detects detected a downgrade attack.

TBA

22 AUTHENTICATION_REQUEST: The server indication indicates to the client that EAP request is signaled in
the PA message.

TBA message contains an EAP request.

23 AUTHENTICATION_REPLY: The client indication indicates to the server that
EAP response is signaled in
the PA message. message contains an EAP response.

The following PCP Option Codes are to be options have been allocated in the mandatory-
to-process range from the standards action Standards
Action range (the registry for PCP Options options is maintained in http://www.iana.org/assignments/pcp-
parameters):
<http://www.iana.org/assignments/pcp-parameters>):

7.1. NONCE

Option

Name: NONCE

option-code: TBA-130 in the mandatory-to-process range (IANA). NONCE.

Value: 4.

Purpose: See Section 5.3.

Valid for Opcodes: Authentication Opcode.

option-len: Option Length is AUTHENTICATION.

Length: 4 octets.

May appear in: request Request and response.

Maximum occurrences: 1.

7.2. AUTHENTICATION_TAG

Option

Name: AUTHENTICATION_TAG

option-code: TBA-131 in the mandatory-to-process range (IANA). AUTHENTICATION_TAG.

Value: 5.

Purpose: See Section 5.4.

Valid for Opcodes: MAP, PEER and ANNOUNCE Opcodes.

option-len: Variable length. PEER, ANNOUNCE.

Length: variable.

May appear in: request Request and response.

Maximum occurrences: 1.

7.3. PA_AUTHENTICATION_TAG

Option

Name: PA_AUTHENTICATION_TAG

option-code: TBA-132 in the mandatory-to-process range (IANA). PA_AUTHENTICATION_TAG.

Value: 6.

Purpose: See Section 5.5.

Valid for Opcodes: Authentication Opcode.

option-len: Variable length. AUTHENTICATION.

Length: variable.

May appear in: request Request and response.

Maximum occurrences: 1.

7.4. EAP_PAYLOAD

Option

Name: EAP_PAYLOAD.

option-code: TBA-133 in the mandatory-to-process range (IANA).

Value: 7.

Purpose: See Section 5.6.

Valid for Opcodes: Authentication Opcode.

option-len: Variable length. AUTHENTICATION.

Length: variable.

May appear in: request Request and response.

Maximum occurrences: 1.

7.5. PRF

Option

Name: PRF.

option-code: TBA-134 in the mandatory-to-process range (IANA).

Value: 8.

Purpose: See Section 5.7.

Valid for Opcodes: Authentication Opcode.

option-len: Option Length is AUTHENTICATION.

Length: 4 octets.

May appear in: request Request and response.

Maximum occurrences: as many as fit within maximum PCP message size.

7.6. MAC_ALGORITHM

Option

Name: MAC_ALGORITHM.

option-code: TBA-135 in the mandatory-to-process range (IANA).

Value: 9.

Purpose: See Section 5.8.

Valid for Opcodes: Authentication Opcode.

option-len: Option Length is AUTHENTICATION.

Length: 4 octets.

May appear in: request Request and response.

Maximum occurrences: as many as fit within maximum PCP message size.

7.7. SESSION_LIFETIME

Option

Name: SESSION_LIFETIME.

option-code: TBA-136 in the mandatory-to-process range (IANA).

Value: 10.

Purpose: See Section 5.9.

Valid for Opcodes: Authentication Opcode.

option-len: Option Length is AUTHENTICATION

Length: 4 octets.

May appear in: response. Response.

Maximum occurrences: 1.

7.8. RECEIVED_PAK

Option

Name: RECEIVED_PAK.

option-code: TBA-137 in the mandatory-to-process range (IANA).

Value: 11.

Purpose: See Section 5.10.

Valid for Opcodes: Authentication Opcode.

option-len: Option Length is AUTHENTICATION.

Length: 4 octets.

May appear in: request Request and response.

Maximum occurrences: 1.

7.9. ID_INDICATOR

Option

Name: ID_INDICATOR.

option-code: TBA-138 in the mandatory-to-process range (IANA).

Value: 12.

Purpose: See Section 5.11.

Valid for Opcodes: Authentication Opcode.

option-len: Variable length. AUTHENTICATION.

Length: variable.

May appear in: response. Response.

Maximum occurrences: 1.

8. Security Considerations

As described in this work, specification, after a successful EAP
authentication process is performed between two PCP devices, an MSK
will be exported. The MSK will be used to derive the transport keys
to generate MAC digests for subsequent PCP message exchanges.
However, before a transport key has been generated, the PA messages
exchanged within a PA session have little cryptographic protection,
and if there is no already
established already-established security channel between two
session partners, these messages are subject to man-in-the-middle
attacks and DOS DoS attacks. For instance, the initial PA-Server and
PA-Client message exchange is vulnerable to spoofing attacks attacks, as
these messages are not authenticated and integrity protected. In
addition, because the PRF and MAC algorithms are transported at this
stage, an attacker may try to remove the PRF and MAC options
containing strong algorithms from the initial PA-Server message and
force the client to choose the weakest algorithms. Therefore, the
server needs to guarantee that all the PRF and MAC algorithms for
which it provides support for are strong enough.

In order to prevent very basic DOS DoS attacks, a PCP device SHOULD
generate state information as little as possible in the initial PA-
Server
PA-Server and PA-Client message exchanges. The choice of EAP method
is also very important. The selected EAP method must (1) be
resilient to
the attacks that are possible in an insecure network
environment, (2) provide user-identity confidentiality, confidentiality and protection
against dictionary attacks, and (3) support session-key
establishment.

When a PCP proxy [I-D.ietf-pcp-proxy] [RFC7648] is located between a PCP server and
PCP clients, the proxy may perform authentication with the PCP server
before it processes requests from the clients. In addition,
re-authentication between the PCP proxy and PCP server will not
interrupt the service that the proxy provides to the clients clients, since
the proxy is still allowed to send common PCP messages to the
PCP server during that period.

9. Acknowledgements

Thanks to Dan Wing, Prashanth Patil, Dave Thaler, Peter Saint-Andre,
Carlos Pignataro, Brian Haberman, Paul Kyzivat, Jouni Korhonen,
Stephen Farrell and Terry Manderson References

9.1. Normative References

[RFC2119] Bradner, S., "Key words for the valuable comments.

10. Change Log

[Note: This section should be removed by the RFC Editor upon
publication]

10.1. Changes from wasserman-pcp-authentication-02 use in RFCs to ietf-pcp-
authentication-00

o Added discussion Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.

[RFC3629] Yergeau, F., "UTF-8, a transformation format of in-band ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>.

[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., 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.

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

o Specify that when a PCP device receives a PCP-Auth-Server or a
PCP-Auth-Client 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.

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

o Editorial changes, added use cases to introduction.

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

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

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

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

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

10.5. Changes from ietf-pcp-authentication-02 to -03

o Change the name "PCP-Auth-Request" to "PCP-Auth-Server"

o Change the name "PCP-Auth-Response" to "PCP-Auth-Client"

o Specify two new sequence numbers for common PCP messages in the
PCP SA, and describe how to use them

o Specify a Authentication Tag Option for PCP Common Messages

o Introduce the scenario where a EAP message has to be divided into
multiple sections and transported in different PCP-Auth messages
(for the reasons of MTU), and introduce how to use PCP-Auth-
Acknowledge messages to ensure reliable packet delivery in this
case.

10.6. Changes from ietf-pcp-authentication-03 to -04

o Change the name "PCP-Auth" to "PA".

o Refine the retransmission policies.

o Add more discussion about the sequence number management .

o Provide the discussion about how to instruct a PCP client to
choose proper credential during authentication, and an ID
Indicator Option is defined for that purpose.

10.7. Changes from ietf-pcp-authentication-04 to -05

o Add contents in IANA considerations.

o Add discussions in fragmentation.

o Refine the PA messages retransmission policies.

o Add IANA considerations.

10.8. Changes from ietf-pcp-authentication-05 to -06

o Added mechanism to handle algorithm downgrade attack.

o Updated Security Considerations section.

o Updated ID Indicator Option.

11. References

11.1. Normative References

[I-D.ietf-pcp-proxy]
Perreault, S., Boucadair, M., Penno, R., Wing, D., and S.
Cheshire, "Port Control Protocol (PCP) Proxy Function",
draft-ietf-pcp-proxy-09 (work in progress), July 2015.

[I-D.ietf-precis-saslprepbis]
Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", draft-ietf-precis-
saslprepbis-18 (work in progress), May 2015.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.

[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>.

[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<http://www.rfc-editor.org/info/rfc3748>.

[RFC4868] Kelly, S. H.
Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<http://www.rfc-editor.org/info/rfc3748>.

[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, 10.17487/
RFC4868, May 2007,
<http://www.rfc-editor.org/info/rfc4868>.

[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication
Protocol Tunneled Transport Layer Security Authenticated
Protocol Version 0 (EAP-TTLSv0)", RFC 5281, DOI 10.17487/RFC5281, 10.17487/
RFC5281, August 2008,
<http://www.rfc-editor.org/info/rfc5281>.

[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI
10.17487/RFC6887, April 2013,
<http://www.rfc-editor.org/info/rfc6887>.

[RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
"Tunnel Extensible Authentication Protocol (TEAP) Version
1", RFC 7170, DOI 10.17487/RFC7170, May 2014,
<http://www.rfc-editor.org/info/rfc7170>.

[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <http://www.rfc-editor.org/info/rfc7296>.

11.2.

[RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", RFC 7613, DOI
10.17487/RFC7613, August 2015,
<http://www.rfc-editor.org/info/rfc7613>.

[RFC7648] Perreault, S., Boucadair, M., Penno, R., Wing, D., and S.
Cheshire, "Port Control Protocol (PCP) Proxy Function",
RFC 7648, DOI 10.17487/RFC7648, September 2015,
<http://www.rfc-editor.org/info/rfc7648>.

9.2. Informative References

[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
March 2008, <http://www.rfc-editor.org/info/rfc5216>.

[RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication
Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method",
RFC 5433, DOI 10.17487/RFC5433, February 2009,
<http://www.rfc-editor.org/info/rfc5433>.

[RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved
Extensible Authentication Protocol Method for 3rd
Generation Authentication and Key Agreement (EAP-AKA')",
RFC 5448, DOI 10.17487/RFC5448, May 2009,
<http://www.rfc-editor.org/info/rfc5448>.

Acknowledgements

Thanks to Dan Wing, Prashanth Patil, Dave Thaler, Peter Saint-Andre,
Carlos Pignataro, Brian Haberman, Paul Kyzivat, Jouni Korhonen,
Stephen Farrell, and Terry Manderson for their valuable comments.

Authors' Addresses

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

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

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

Email: hartmans@painless-security.com
URI: http://www.painless-security.com
Dacheng Zhang
Huawei
Beijing
Beijing, China
China

Email: zhang_dacheng@hotmail.com

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

Email: tireddy@cisco.com