One document matched: draft-ietf-pcp-authentication-14.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2629 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-pcp-authentication-14"
ipr="trust200902" updates="6887">
<front>
<title abbrev="PCP Authentication">Port Control Protocol (PCP)
Authentication Mechanism</title>
<author fullname="Margaret Wasserman" initials="M." surname="Wasserman">
<organization>Painless Security</organization>
<address>
<postal>
<street>356 Abbott Street</street>
<city>North Andover</city>
<region>MA</region>
<code>01845</code>
<country>USA</country>
</postal>
<phone>+1 781 405 7464</phone>
<email>mrw@painless-security.com</email>
<uri>http://www.painless-security.com</uri>
</address>
</author>
<author fullname="Sam Hartman" initials="S." surname="Hartman">
<organization>Painless Security</organization>
<address>
<postal>
<street>356 Abbott Street</street>
<city>North Andover</city>
<region>MA</region>
<code>01845</code>
<country>USA</country>
</postal>
<email>hartmans@painless-security.com</email>
<uri>http://www.painless-security.com</uri>
</address>
</author>
<author fullname="Dacheng Zhang" initials="D." surname="Zhang">
<organization>Huawei</organization>
<address>
<postal>
<street></street>
<city>Beijing</city>
<region></region>
<code></code>
<country>China</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>zhang_dacheng@hotmail.com</email>
<uri></uri>
</address>
</author>
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Cessna Business Park, Varthur Hobli</street>
<street>Sarjapur Marathalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<email>tireddy@cisco.com</email>
</address>
</author>
<date day="20" month="July" year="2015" />
<abstract>
<t>An IPv4 or IPv6 host can use the Port Control Protocol (PCP) to
flexibly manage the IP address and port mapping information on Network
Address Translators (NATs) or firewalls to facilitate communication with
remote hosts. However, the un-controlled generation or deletion of IP
address mappings on such network devices may cause security risks and
should be avoided. In some cases the client may need to prove that it is
authorized to modify, create or delete PCP mappings. This document
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.</t>
<t>This document updates RFC6887.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Using the Port Control Protocol (PCP) <xref target="RFC6887"></xref>,
an application can flexibly manage the IP address mapping information on
its network address translators (NATs) and firewalls, and control their
policies in processing incoming and outgoing IP packets. Because NATs
and firewalls both play important roles in network security
architectures, there are many situations in which authentication and
access control are required to prevent un-authorized users from
accessing such devices. This document defines a PCP security extension
that enables PCP servers to authenticate their clients with Extensible
Authentication Protocol (EAP). The EAP messages are encapsulated within
PCP messages during transportation.</t>
<t>The following issues are considered in the design of this
extension:</t>
<t><list style="symbols">
<t>Loss of EAP messages during transportation</t>
<t>Reordered delivery of EAP messages</t>
<t>Generation of transport keys</t>
<t>Integrity protection and data origin authentication for PCP
messages</t>
<t>Algorithm agility</t>
</list>The mechanism described in this document meets the security
requirements to address the Advanced Threat Model described in the base
PCP specification <xref target="RFC6887"></xref>. This mechanism can be
used to secure PCP in the following situations:</t>
<t><list style="symbols">
<t>On security infrastructure equipment, such as corporate
firewalls, that do not create implicit mappings for specific
traffic.</t>
<t>On equipment (such as CGNs or service provider firewalls) that
serve multiple administrative domains and do not have a mechanism to
securely partition traffic from those domains.</t>
<t>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.</t>
</list></t>
</section>
<section title="Terminology ">
<t>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 <xref
target="RFC2119"></xref>.</t>
<t>Most of the terms used in this document are introduced in <xref
target="RFC6887"></xref>.</t>
<t>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 a
EAP peer <xref target="RFC3748"></xref>, and it is the responsibility of
a PCP client to provide the credentials when authentication is
required.</t>
<t>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 <xref
target="RFC3748"></xref>. 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.</t>
<t>PCP-Authentication (PA) Session: A series of PCP message exchanges
transferred between a PCP client and a PCP server. The PCP messages
involved within a session includes the PA messages used to perform EAP
authentication, key distribution and session management, and the common
PCP messages secured with the keys distributed during authentication.
Each PA session is assigned a distinctive Session ID.</t>
<t>Session Partner: A PCP implementation involved within a PA session.
Each PA session has two session partners (a PCP server and a PCP
client).</t>
<t>PCP device: A PCP client or a PCP server.</t>
<t>Session Lifetime: The lifetime associated with a PA session, which
decides the lifetime of the current authorization given to the PCP
client.</t>
<t>PCP Security Association (PCP SA): A PCP security association is
formed between a PCP client and a PCP server by sharing cryptographic
keying material and associated context. The formed duplex security
association is used to protect the bidirectional PCP signaling traffic
between the PCP client and PCP server.</t>
<t>Master Session Key (MSK): A key derived by the partners of a PA
session, using an EAP key generating method (e.g., the one defined in
<xref target="RFC5448"></xref>).</t>
<t>PCP-Authentication (PA) message: A PCP message containing an
AUTHENTICATION Opcode. Particularly, 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 specified in <xref target="RFC6887"></xref>, and a
PA-Client message is a PCP request message. This document specifies an
option, the PA_AUTHENTICATION_TAG Option defined in <xref
target="tagB"></xref> for PCP authentication, to provide integrity
protection and message origin authentication for PA messages.</t>
<t>Common PCP message: A PCP message which 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.</t>
</section>
<section title="Protocol Details">
<section anchor="initiation" title="Session Initiation">
<t>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 a 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.</t>
<section anchor="client"
title="Authentication triggered by the client">
<t>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. <xref
target="format"></xref> 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 as 0. The PA-Client message MUST also
contain a NONCE option defined in <xref target="nonce"></xref> which
consists of a random nonce.</t>
<t>After receiving the PA-Initiation, if the PCP server agrees to
initiate a PA session with the PCP client, it will reply with a
PA-Server message which 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
distinctly identify this session, and fill 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 as 0. 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.</t>
<t><figure>
<artwork><![CDATA[
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) |
]]></artwork>
</figure></t>
</section>
<section title="Authentication triggered by the server">
<t>In the scenario where a PCP server receives a common PCP request
message from a PCP client which needs to be authenticated, the PCP
server rejects the request with a AUTHENTICATION_REQUIRED error code
and can reply with a 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
as 0. If the PCP client retries the common request before EAP
authentication is successful then it will receive
AUTHENTICATION_REQUIRED error code from the PCP server. In the PA
messages exchanged afterwards in this session, the Session ID will
be used in order to help session partners distinguish the messages
within this session from those not within. When the PCP client
receives this initial 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 which 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.</t>
<t><figure>
<artwork><![CDATA[
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) |
]]></artwork>
</figure></t>
</section>
<section anchor="EAP" title="Authentication using EAP">
<t>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 transportation 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 cannot generate an EAP
response immediately due to certain reasons (e.g., waiting for human
input to construct a EAP message or due to EAP message fragmentation
waiting for the additional PA messages in order to construct a
complete EAP message), the PCP device MUST reply with a
PA-Acknowledgement message (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 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.</t>
<t>In this approach, PCP client and a PCP server MUST perform a
key-generating EAP method in authentication. Particularly, a PCP
authentication implementation MUST support EAP-TTLS <xref
target="RFC5281"></xref> and SHOULD support TEAP <xref
target="RFC7170"></xref>. 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
Function (PRF) for the transport key derivation and a 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 (Message Authentication
Code) algorithm that the PCP server supports. Moreover, in the first
PA-Server message, the server MAY also attach an ID_INDICATOR Option
defined in <xref target="ID"></xref> to direct the client to choose
correct credentials. After receiving the options, the PCP client
MUST select the PRF and the MAC algorithm which it would like to
use, and then adds the associated PRF and MAC Algorithm Options to
the next PA-Client message.</t>
<t>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 use the
derived transport key to generate a digest for the message. The
digest is transported within an PA_AUTHENTICATION_TAG Option for PCP
Auth. A more detailed description of generating the authentication
data can be found in <xref target="AuthG"></xref>. In addition, the
PA-Server message MUST also contain a SESSION_LIFETIME Option
defined in <xref target="life"></xref> which 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 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 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 common PCP request
within the PA session without AUTHENTICATION_TAG option then the PCP
server rejects the request by returning AUTHENTICATION_REQUIRED
error code.</t>
<t>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.</t>
</section>
</section>
<section anchor="recovery" title="Recovery from lost PA session">
<t>If a PCP server resets or loses the PCP SA due to reboot, power
failure, or any reason then it sends unsolicited ANNOUNCE response as
explained in section 14.1.3 of <xref target="RFC6887"></xref> to the
PCP client. Upon receiving the ANNOUNCE response with an anomalous
Epoch time, 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:</t>
<t><list style="symbols">
<t>PCP client sends integrity-protected unicast ANNOUNCE request
to the PCP server to check if the PCP server has indeed lost the
state or an attacker has sent the ANNOUNCE response. <list
style="symbols">
<t>If integrity-protected success response is recevied 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.</t>
<t>If the PCP server responds to the ANNOUNCE request with
UNKNOWN_SESSION_ID error code then the PCP client MUST
initiate full EAP authentication with the PCP server as
explained in <xref target="client"></xref>. After EAP
authentication is successful PCP client updates the PCP SA and
issues new common PCP requests to recreate any lost mapping
state.</t>
</list></t>
<t>In a scenario where the PCP server has lost the PCP SA but did
not inform the PCP client, if the PCP client sends PCP request
integrity-protected then the PCP server rejects the request with
UNKNOWN_SESSION_ID error code. The PCP client then initiates full
EAP authentication with the PCP server as explained in <xref
target="client"></xref> and updates the PCP SA after successful
authentication.</t>
</list></t>
<t>If the PCP client resets or loses the PCP SA due to reboot, power
failure, or any reason and sends common PCP request then the PCP
server rejects the request with AUTHENTICATION_REQUIRED error code.
The PCP client MUST authenticate with the PCP server and after EAP
authentication is successful retry the common PCP request with
AUTHENTICATION_TAG option. The PCP server MUST update the PCP SA after
successful EAP authentication.</t>
</section>
<section anchor="termination" title="Session Termination">
<t>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 "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 the interval between the first
two notifications is at least 250 ms, and the interval between
subsequent notification at least doubles.</t>
<t>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"). After receiving a
termination-indicating message from the PCP client, a PCP server MUST
respond with a termination-indicating PA response and remove the PCP
SA immediately. When the PCP client receives the
termination-indicating PA response, it MUST remove the associated PCP
SA immediately.</t>
</section>
<section title="Session Re-Authentication">
<t>A session partner may select 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:<list style="symbols">
<t>The session lifetime needs to be extended.</t>
<t>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.</t>
</list>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 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 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 <xref target="AuthR"></xref>. The result code for PA-Sever message
carrying EAP request will be set to AUTHENTICATION_REQUIRED and
PA-Client message carrying EAP response will be set to
AUTHENTICATION_REPLY.</t>
<t>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 which indicates the new
lifetime of the PA session. PA and PCP message sequence numbers must
also be reset to zero.</t>
<t>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 session lifetime has expired then PA session MUST
be terminated immediately.</t>
<t>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 re-authentication request from the PCP client
after it had signaled re-authentication request then it should discard
its request and respond to the re-authentication request from the PCP
client.</t>
</section>
</section>
<section title="PA Security Association">
<t>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:</t>
<t><list style="symbols">
<t>IP address and UDP port number of the PCP client</t>
<t>IP address and UDP port number of the PCP server</t>
<t>Session Identifier</t>
<t>Sequence number for the next outgoing PA message</t>
<t>Sequence number for the next incoming PA message</t>
<t>Sequence number for the next outgoing common PCP message</t>
<t>Sequence number for the next incoming common PCP message</t>
<t>Last outgoing message payload</t>
<t>Retransmission interval</t>
<t>The master session key (MSK) generated by the EAP method.</t>
<t>The MAC algorithm that the transport key should use to generate
digests for PCP messages.</t>
<t>The pseudo random function negotiated in the initial PA-Server
and PA-Client message exchange for the transport key derivation</t>
<t>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.</t>
<t>The nonce selected by the PCP client at the initiation of the
session.</t>
<t>The Key ID associated with Transport key.</t>
</list></t>
<t>Particularly, the transport key is computed in the following way:
Transport key = prf(MSK, "IETF PCP" || Session ID || Nonce || key ID),
where:</t>
<t><list style="symbols">
<t>prf: The pseudo-random function assigned in the Pseudo-random
function parameter.</t>
<t>MSK: The master session key generated by the EAP method.</t>
<t>"IETF PCP": The ASCII code representation of the non-NULL
terminated string (excluding the double quotes around it).</t>
<t>'||' : is the concatenation operator.</t>
<t>Session ID: The ID of the session which the MSK is derived
from.</t>
<t>Nonce: The nonce selected by the client and transported in the
Initial PA-Client message.</t>
<t>Key ID: The ID assigned for the transport key.</t>
</list></t>
</section>
<section title="Packet Format ">
<section anchor="format" title="Packet Format of PCP Auth Messages">
<t>The format of the PA-Server message is identical to the response
message format specified in Section 7.2 of <xref
target="RFC6887"></xref>. The result code for PA-Sever message
carrying EAP request MUST be set to AUTHENTICATION_REQUEST.</t>
<t>As illustrated in Figure 1, this document updates the reserved
field in the request header specified in Section 7.1 of <xref
target="RFC6887"></xref> to carry Opcode-specific data.</t>
<t><figure>
<artwork><![CDATA[ 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]]></artwork>
</figure></t>
<t>As illustrated in Figure 2, the PA-Client messages 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 <xref target="RFC6887"></xref>. The result code for
PA-Client message carrying EAP response MUST be set to
AUTHENTICATION_REPLY.</t>
<figure>
<artwork><![CDATA[ 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]]></artwork>
</figure>
<t></t>
<t>The Requested Lifetime field of PA-Client message and Lifetime
field of PA-Server message are both set to 0 on transmission and
ignored on reception.</t>
</section>
<section title="Opcode-specific information of AUTHENTICATION Opcode">
<t>The following diagram shows the format of the Opcode-specific
information for the AUTHENTICATION Opcode.</t>
<t><figure>
<artwork><![CDATA[ 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure></t>
<t><list style="empty">
<t>Session ID: This field contains a 32-bit PA session
identifier.</t>
<t>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.</t>
</list></t>
</section>
<section anchor="nonce" title="NONCE Option">
<t>Because the session identifier of a PA session is determined by the
PCP server, a PCP client does not know the session identifier which
will be used when it sends out a PA-Initiation message. In order to
prevent an attacker from interrupting the authentication process by
sending off-line generated 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.<figure>
<artwork><![CDATA[ 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
</figure><list style="empty">
<t>Option Code: TBA-130.</t>
<t>Reserved: 8 bits. MUST be set to 0 on transmission and MUST be
ignored on reception.</t>
<t>Option-Length: 4 octets.</t>
<t>Nonce: A random 32 bit number which is transported within a
PA-Initiation message and the corresponding reply message from the
PCP server.</t>
</list></t>
</section>
<section anchor="tag" title="AUTHENTICATION_TAG Option">
<t><figure>
<artwork><![CDATA[ 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) |
~ ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
</figure></t>
<t>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.<list style="empty">
<t>Option Code: TBA-131.</t>
<t>Reserved: 8 bits. MUST be set to 0 on transmission and MUST be
ignored on reception.</t>
<t>Option-Length: The length of the AUTHENTICATION_TAG Option for
Common PCP message (in octets), including the 12 octet fixed
header and the variable length of the authentication data.</t>
<t>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.</t>
<t>Sequence Number: A 32-bit sequence number. In this solution, a
sequence number needs to be incremented on every new
(non-retransmission) outgoing common PCP message in order to
provide ordering guarantee for common PCP messages.</t>
<t>Key ID: The ID associated with the transport key used to
generate authentication data. This field is filled with zero if
the MSK is directly used to secure the message.</t>
<t>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 0's when necessary.</t>
</list></t>
</section>
<section anchor="tagB" title="PA_AUTHENTICATION_TAG option">
<t>This option is used to provide message authentication for PA
messages. Compared with 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 AUTHENTICATION Opcode.</t>
<t><figure>
<artwork><![CDATA[ 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) |
~ ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
</figure><list style="empty">
<t>Option Code: TBA-132.</t>
<t>Reserved: 8 bits. MUST be set to 0 on transmission and MUST be
ignored on reception.</t>
<t>Option-Length: The length of the PA_AUTHENTICATION Option for
PCP Auth message (in octet), including the 4 octet fixed header
and the variable length of the authentication data.</t>
<t>Key ID: The ID associated with the transport key used to
generate authentication data. This field is filled with zero if
the MSK is directly used to secure the message.</t>
<t>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.</t>
</list></t>
</section>
<section anchor="EAPA" title="EAP_PAYLOAD Option">
<t><figure>
<artwork><![CDATA[ 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 |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
</figure></t>
<t><list style="empty">
<t>Option Code: TBA-133.</t>
<t>Reserved: 8 bits. MUST be set to 0 on transmission and MUST be
ignored on reception.</t>
<t>Option-Length: Variable</t>
<t>EAP Message: The EAP message transferred. Note this field MUST
end on a 32-bit boundary, padded with 0's when necessary.</t>
</list></t>
</section>
<section anchor="PRF" title="PRF Option">
<t><figure>
<artwork><![CDATA[ 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
</figure></t>
<t>Option Code: TBA-134.</t>
<t>Reserved: 8 bits. MUST be set to 0 on transmission and MUST be
ignored on reception.</t>
<t>Option-Length: 4 octets.</t>
<t>PRF: The Pseudo-Random Function which the sender supports to
generate an MSK. This field contains an IKEv2 Transform ID of
Transform Type 2 <xref target="RFC7296"></xref><xref
target="RFC4868"></xref>. A PCP implementation MUST support
PRF_HMAC_SHA2_256 (5).</t>
</section>
<section anchor="MAC" title="MAC_ALGORITHM Option">
<t><figure>
<artwork><![CDATA[ 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure></t>
<t>Option Code: TBA-135.</t>
<t>Reserved: 8 bits. MUST be set to 0 on transmission and MUST be
ignored on reception.</t>
<t>Option-Length: 4 octets.</t>
<t>MAC Algorithm ID: Indicate the MAC algorithm which the sender
supports to generate authentication data. The MAC Algorithm ID field
contains an IKEv2 Transform ID of Transform Type 3 <xref
target="RFC7296"></xref><xref target="RFC4868"></xref>. A PCP
implementation MUST support AUTH_HMAC_SHA2_256_128 (12).</t>
</section>
<section anchor="life" title="SESSION_LIFETIME Option">
<t><figure>
<artwork><![CDATA[ 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure></t>
<t>Option Code: TBA-136.</t>
<t>Reserved: 8 bits. MUST be set to 0 on transmission and MUST be
ignored on reception.</t>
<t>Option-Length: 4 octets.</t>
<t>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.</t>
</section>
<section anchor="Ack-Seq" title="RECEIVED_PAK Option">
<t>This option is used in a PA-Acknowledgement message to indicate
that a PA message with the contained sequence number has been
received.<figure>
<artwork><![CDATA[ 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure></t>
<t>Option Code: TBA-137.</t>
<t>Reserved: 8 bits. MUST be set to 0 on transmission and MUST be
ignored on reception.</t>
<t>Option-Length: 4 octets.</t>
<t>Received Sequence Number: The sequence number of the last received
PA message.</t>
</section>
<section anchor="ID" title="ID_INDICATOR Option">
<t>The ID_INDICATOR option is used by the PCP client to determine
which credentials to provide to the PCP server.</t>
<t><figure>
<artwork><![CDATA[ 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 |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure><list style="empty">
<t>Option Code: TBA-138.</t>
<t>Reserved: 8 bits. MUST be set to 0 on transmission and MUST be
ignored on reception.</t>
<t>Option-Length: Variable.</t>
<t>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 and its length is indicated by the
Option-Length field. In particular when a client receives a
ID_INDICATOR option, it MUST NOT rely on the presence of a NUL
character in the wire format data to identify the end of the ID
Indicator field.</t>
<t>The field MUST end on a 32-bit boundary, padded with 0's when
necessary. The ID indicator field is UTF-8 encoded <xref
target="RFC3629"></xref> Unicode string conforming to the
"UsernameCaseMapped" profile of the PRECIS IdentifierClass <xref
target="I-D.ietf-precis-saslprepbis"></xref>. 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 <xref
target="I-D.ietf-precis-saslprepbis"></xref> 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.</t>
</list></t>
</section>
</section>
<section title="Processing Rules">
<section anchor="AuthG" title="Authentication Data Generation">
<t>After successful EAP authentication process, every subsequent PCP
message within the PA session MUST carry an authentication tag which
contains the digest of the PCP message for data origin authentication
and integrity protection.</t>
<t><list style="symbols">
<t>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 the device appends an
PA_AUTHENTICATION_TAG 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,
and sets the Authentication Data field to 0. After this, the
device generates a digest for the entire PCP message (including
the PCP header and PA_AUTHENTICATION_TAG Option) using the
transport key and the associated MAC algorithm, and inserts the
generated digest into the Authentication Data field.</t>
<t>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 the device appends the
AUTHENTICATION_TAG Option at the end of 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 and the Key ID field, and sets
the Authentication Data field to 0. After this, the device
generates a digest for the entire PCP message (including the PCP
header and AUTHENTICATION_TAG Option) using the transport key and
the associated MAC algorithm, and inputs the generated digest into
the Authentication Data field.</t>
</list></t>
</section>
<section anchor="AuthV" title="Authentication Data Validation">
<t>When a device receives a common PCP message with an
AUTHENTICATION_TAG Option for Common PCP Messages, the device needs to
use the Session ID transported in the option to locate the proper 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 <xref
target="AuthC"></xref>), the PCP device stops processing the PCP
message and discards the message silently. After storing the value of
the Authentication field of the AUTHENTICATION_TAG Option, the device
fills the Authentication field with zeros. Then, the device generates
a digest for the message (including the PCP header and 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.</t>
<t>Similarly, when a device receives a PA message with an
PA_AUTHENTICATION_TAG Option for PCP Authentication, the device needs
to use the Session ID transported in the Opcode to locate the proper
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 <xref
target="AuthS"></xref>), the PCP device stops processing the PCP
message and discards the message. After storing the value of the
Authentication field of the PA_AUTHENTICATION_TAG 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) 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.</t>
</section>
<section anchor="AuthR" title="Retransmission Policies for PA Messages">
<t>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 a PA message with a
proper sequence number from the peer. If no such a message is received
the PCP device will re-send the last message according to
retransmission policies. This work reuses the retransmission policies
specified in the base PCP protocol (Section 8.1.1 of [RFC6887]). In
the base PCP protocol, such retransmission policies are only applied
by PCP clients. However, in this work, such retransmission policies
are also applied by the PCP servers. If Maximum retransmission
duration seconds have elapsed and no expected response is received,
the device will terminate the session and discard the current SA.</t>
<t>As illustrated in <xref target="EAP"></xref>, in order to avoid
unnecessary re-transmission, the device receiving a PA message MUST
send a 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.</t>
<t>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 since the devices sending out
those messages do not expect any further PA messages.</t>
<t>When a device receives a re-transmitted 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 identical to the original
message then the device MUST discard it. In order to achieve this
function, the device may need to maintain the last incoming 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 (DoS) attacks. The details of
rate limiting are outside the scope of this specification.</t>
</section>
<section anchor="AuthS" title="Sequence Numbers for PCP Auth Messages">
<t>PCP uses UDP to transport signaling messages. As an un-reliable
transport protocol, UDP does not guarantee ordered packet delivery and
does not provide any protection from packet loss. In order to ensure
the EAP messages are exchanged in a reliable way, every PCP 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, 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 the device maintains. After
confirming that the received message is valid, the device increments
the incoming sequence number maintained in the SA by 1.</t>
<t>The above rules are not applicable to PA-Acknowledgement messages
(i.e., PA messages containing a RECEIVED_PAK Option). A
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 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.</t>
<t>Another exception is the message retransmission scenario. As
discussed in <xref target="AuthR"></xref>, when a PCP device does not
receive any response from its session partner it needs to retransmit
the last outgoing PA message following the retransmission procedure
specified in section 8.1.1 of <xref target="RFC6887"></xref>. The
original message and duplicate messages MUST be bit-wise 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.</t>
</section>
<section anchor="AuthC" title="Sequence Numbers for Common PCP Messages">
<t>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.</t>
<t>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 the device
maintains. 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.</t>
<t>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 <xref
target="RFC6887"></xref>, if a PCP client is no longer interested in
the PCP transaction and has not yet received a PCP response from the
server then it will stop retransmitting the PCP request. After that,
the PCP client might generate new PCP requests for other 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.</t>
<t>Note that in the base PCP specification <xref
target="RFC6887"></xref>, 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.</t>
</section>
<section anchor="AuthM" title="MTU Considerations">
<t>EAP methods are responsible for MTU handling, so no special
facilities are required in PCP to deal with MTU issues. Particularly,
EAP lower layers indicate to EAP methods and AAA servers the MTU of
the lower layer. EAP methods such as EAP-TLS <xref
target="RFC5216"></xref>, TEAP <xref target="RFC7170"></xref>, and
others that are likely to exceed reasonable MTUs provide support for
fragmentation and reassembly. Others, such as EAP-GPSK <xref
target="RFC5433"></xref> assume they will never send packets larger
than the MTU and use small EAP packets.</t>
<t>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.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>The following PCP Opcode is to be allocated in the
mandatory-to-process range from the standards action range (the registry
for PCP Opcodes is maintained in
http://www.iana.org/assignments/pcp-parameters):</t>
<t>TBA AUTHENTICATION Opcode.</t>
<t>The following PCP result codes are to be allocated in the
mandatory-to-process range from the standards action range (the registry
for PCP result codes is maintained in
http://www.iana.org/assignments/pcp-parameters):</t>
<t><list style="empty">
<t>TBA INITIATION: The client indication to the server for
authentication.</t>
<t>TBA AUTHENTICATION_REQUIRED: The error response is signaled to
the client that EAP authentication is required.</t>
<t>TBA AUTHENTICATION_FAILED: This error response is signaled to the
client if EAP authentication had failed.</t>
<t>TBA AUTHENTICATION_SUCCEEDED:This success response is signaled to
the client if EAP authentication had succeeded.</t>
<t>TBA AUTHORIZATION_FAILED: This error response is signaled to the
client if the EAP authentication had succeeded but authorization
failed.</t>
<t>TBA SESSION_TERMINATED: This PCP result code indicates to the
partner that the PA session must be terminated.</t>
<t>TBA UNKNOWN_SESSION_ID: The error response is signaled from the
PCP server that there is no known PA session associated with the
Session ID signaled in the PA request or common PCP request from the
PCP client.</t>
<t>TBA DOWNGRADE_ATTACK_DETECTED: This error response is signaled to
the client if the server detects downgrade attack.</t>
<t>TBA AUTHENTICATION_REQUEST: The server indication to the client
that EAP request is signaled in the PA message.</t>
<t>TBA AUTHENTICATION_REPLY: The client indication to the server
that EAP response is signaled in the PA message.</t>
</list></t>
<t>The following PCP Option Codes are to be allocated in the
mandatory-to-process range from the standards action range (the registry
for PCP Options is maintained in
http://www.iana.org/assignments/pcp-parameters):</t>
<section title="NONCE">
<t><list style="hanging">
<t hangText="Option Name:">NONCE</t>
<t hangText="option-code:">TBA-130 in the mandatory-to-process
range (IANA).</t>
<t hangText="Purpose:">See <xref target="nonce"></xref>.</t>
<t hangText="Valid for Opcodes:">Authentication Opcode.</t>
<t hangText="option-len:">Option Length is 4 octets.</t>
<t hangText="May appear in:">request and response.</t>
<t hangText="Maximum occurrences:">1.</t>
</list></t>
</section>
<section title="AUTHENTICATION_TAG">
<t><list style="hanging">
<t hangText="Option Name:">AUTHENTICATION_TAG</t>
<t hangText="option-code:">TBA-131 in the mandatory-to-process
range (IANA).</t>
<t hangText="Purpose:">See <xref target="tag"></xref>.</t>
<t hangText="Valid for Opcodes:">MAP, PEER and ANNOUNCE
Opcodes.</t>
<t hangText="option-len:">Variable length.</t>
<t hangText="May appear in:">request and response.</t>
<t hangText="Maximum occurrences:">1.</t>
</list></t>
</section>
<section title="PA_AUTHENTICATION_TAG">
<t><list style="hanging">
<t hangText="Option Name:">PA_AUTHENTICATION_TAG</t>
<t hangText="option-code:">TBA-132 in the mandatory-to-process
range (IANA).</t>
<t hangText="Purpose:">See <xref target="tagB"></xref>.</t>
<t hangText="Valid for Opcodes:">Authentication Opcode.</t>
<t hangText="option-len:">Variable length.</t>
<t hangText="May appear in:">request and response.</t>
<t hangText="Maximum occurrences:">1.</t>
</list></t>
</section>
<section title="EAP_PAYLOAD">
<t><list style="hanging">
<t hangText="Option Name:">EAP_PAYLOAD.</t>
<t hangText="option-code:">TBA-133 in the mandatory-to-process
range (IANA).</t>
<t hangText="Purpose:">See <xref target="EAPA"></xref>.</t>
<t hangText="Valid for Opcodes:">Authentication Opcode.</t>
<t hangText="option-len:">Variable length.</t>
<t hangText="May appear in:">request and response.</t>
<t hangText="Maximum occurrences:">1.</t>
</list></t>
</section>
<section title="PRF">
<t><list style="hanging">
<t hangText="Option Name:">PRF.</t>
<t hangText="option-code:">TBA-134 in the mandatory-to-process
range (IANA).</t>
<t hangText="Purpose:">See <xref target="PRF"></xref>.</t>
<t hangText="Valid for Opcodes:">Authentication Opcode.</t>
<t hangText="option-len:">Option Length is 4 octets.</t>
<t hangText="May appear in:">request and response.</t>
<t hangText="Maximum occurrences:">as many as fit within maximum
PCP message size.</t>
</list></t>
</section>
<section title="MAC_ALGORITHM">
<t><list style="hanging">
<t hangText="Option Name:">MAC_ALGORITHM.</t>
<t hangText="option-code:">TBA-135 in the mandatory-to-process
range (IANA).</t>
<t hangText="Purpose:">See <xref target="MAC"></xref>.</t>
<t hangText="Valid for Opcodes:">Authentication Opcode.</t>
<t hangText="option-len:">Option Length is 4 octets.</t>
<t hangText="May appear in:">request and response.</t>
<t hangText="Maximum occurrences:">as many as fit within maximum
PCP message size.</t>
</list></t>
</section>
<section title="SESSION_LIFETIME">
<t><list style="hanging">
<t hangText="Option Name:">SESSION_LIFETIME.</t>
<t hangText="option-code:">TBA-136 in the mandatory-to-process
range (IANA).</t>
<t hangText="Purpose:">See <xref target="life"></xref>.</t>
<t hangText="Valid for Opcodes:">Authentication Opcode.</t>
<t hangText="option-len:">Option Length is 4 octets.</t>
<t hangText="May appear in:">response.</t>
<t hangText="Maximum occurrences:">1.</t>
</list></t>
</section>
<section title="RECEIVED_PAK">
<t><list style="hanging">
<t hangText="Option Name:">RECEIVED_PAK.</t>
<t hangText="option-code:">TBA-137 in the mandatory-to-process
range (IANA).</t>
<t hangText="Purpose:">See <xref target="Ack-Seq"></xref>.</t>
<t hangText="Valid for Opcodes:">Authentication Opcode.</t>
<t hangText="option-len:">Option Length is 4 octets.</t>
<t hangText="May appear in:">request and response.</t>
<t hangText="Maximum occurrences:">1.</t>
</list></t>
</section>
<section title="ID_INDICATOR">
<t><list style="hanging">
<t hangText="Option Name:">ID_INDICATOR.</t>
<t hangText="option-code:">TBA-138 in the mandatory-to-process
range (IANA).</t>
<t hangText="Purpose:">See <xref target="ID"></xref>.</t>
<t hangText="Valid for Opcodes:">Authentication Opcode.</t>
<t hangText="option-len:">Variable length.</t>
<t hangText="May appear in:">response.</t>
<t hangText="Maximum occurrences:">1.</t>
</list></t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>In this work, 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
security channel between two session partners, these messages are
subject to man-in-the-middle attacks and DOS attacks. For instance, the
initial PA-Server and PA-Client message exchange is vulnerable to
spoofing attacks as these messages are not authenticated and integrity
protected. In addition, because the PRF and MAC algorithms are
transported at this stage, an attacker may try to remove the PRF and MAC
options containing strong algorithms from the initial PA-Server message
and force the client choose the weakest algorithms. Therefore, the
server needs to guarantee that all the PRF and MAC algorithms it
provides support for are strong enough.</t>
<t>In order to prevent very basic DOS attacks, a PCP device SHOULD
generate state information as little as possible in the initial
PA-Server and PA-Client message exchanges. The choice of EAP method is
also very important. The selected EAP method must be resilient to the
attacks possible in an insecure network environment, provide
user-identity confidentiality, protection against dictionary attacks,
and support session-key establishment.</t>
<t>When a PCP proxy <xref target="I-D.ietf-pcp-proxy"></xref> 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 since the proxy is still allowed to send common PCP messages to
the PCP server during that period.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>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 the valuable comments.</t>
</section>
<section title="Change Log">
<t>[Note: This section should be removed by the RFC Editor upon
publication]</t>
<section title="Changes from wasserman-pcp-authentication-02 to ietf-pcp-authentication-00">
<t><list style="symbols">
<t>Added discussion of in-band and out-of-band key management
options, leaving choice open for later WG decision.</t>
<t>Removed support for fragmenting EAP messages, as that is
handled by EAP methods.</t>
</list></t>
</section>
<section title="Changes from wasserman-pcp-authentication-01 to -02">
<t><list style="symbols">
<t>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.</t>
<t>Add the key ID field into the authentication tag option so that
a MSK can generate multiple transport keys.</t>
<t>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.</t>
<t>Add the support of fragmenting EAP messages.</t>
</list></t>
</section>
<section title="Changes from ietf-pcp-authentication-00 to -01">
<t><list style="symbols">
<t>Editorial changes, added use cases to introduction.</t>
</list></t>
</section>
<section title="Changes from ietf-pcp-authentication-01 to -02">
<t><list style="symbols">
<t>Add the support of re-authentication initiated by PCP
server.</t>
<t>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.</t>
<t>Discuss the format of the PCP-Auth-Acknowledge message.</t>
<t>Remove the redundant information from the Auth Opcode, and
specify new result codes transported in PCP packet headers</t>
<t></t>
</list></t>
</section>
<section title="Changes from ietf-pcp-authentication-02 to -03">
<t><list style="symbols">
<t>Change the name "PCP-Auth-Request" to "PCP-Auth-Server"</t>
<t>Change the name "PCP-Auth-Response" to "PCP-Auth-Client"</t>
<t>Specify two new sequence numbers for common PCP messages in the
PCP SA, and describe how to use them</t>
<t>Specify a Authentication Tag Option for PCP Common Messages</t>
<t>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.</t>
</list></t>
</section>
<section title="Changes from ietf-pcp-authentication-03 to -04">
<t><list style="symbols">
<t>Change the name "PCP-Auth" to "PA".</t>
<t>Refine the retransmission policies.</t>
<t>Add more discussion about the sequence number management .</t>
<t>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.</t>
</list></t>
</section>
<section title="Changes from ietf-pcp-authentication-04 to -05">
<t><list style="symbols">
<t>Add contents in IANA considerations.</t>
<t>Add discussions in fragmentation.</t>
<t>Refine the PA messages retransmission policies.</t>
<t>Add IANA considerations.</t>
</list></t>
</section>
<section title="Changes from ietf-pcp-authentication-05 to -06">
<t><list style="symbols">
<t>Added mechanism to handle algorithm downgrade attack.</t>
<t>Updated Security Considerations section.</t>
<t>Updated ID Indicator Option.</t>
</list></t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.I-D.ietf-precis-saslprepbis'?>
<?rfc include='reference.I-D.ietf-pcp-proxy'?>
<?rfc include='reference.RFC.3629'?>
<?rfc include='reference.RFC.3748'?>
<?rfc include='reference.RFC.7296'?>
<?rfc include='reference.RFC.4868'?>
<?rfc include='reference.RFC.5281'?>
<?rfc include='reference.RFC.6887'?>
<?rfc include='reference.RFC.7170'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.5448'?>
<?rfc include='reference.RFC.5216'?>
<?rfc include='reference.RFC.5433'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:24:49 |