One document matched: draft-ietf-pcp-authentication-03.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="exp" docName="draft-ietf-pcp-authentication-03"
ipr="trust200902">
<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/>
<city>Beijing</city>
<region/>
<code/>
<country>China</country>
</postal>
<phone/>
<facsimile/>
<email>zhangdacheng@huawei.com</email>
<uri/>
</address>
</author>
<date day="7" month="February" year="2014"/>
<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 communications
with remote hosts. However, the un-controlled generation or deletion of
IP address mappings on such network devices may cause security risks and
should be avoided. In some cases the client may need to prove that it is
authorized to modify, create or delete PCP mappings. This document
proposes an in-band authentication mechanism for PCP that can be used in
those cases. The Extensible Authentication Protocol (EAP) is used to
perform authentication between PCP devices.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Using the Port Control Protocol (PCP) <xref target="RFC6887"/>, an
IPv4 or IPv6 host can flexibly manage the IP address mapping information
on its network address translators (NATs) and firewalls, and control
their policies in processing incoming and outgoing IP packets. Because
NATs and firewalls both play important roles in network security
architectures, there are many situations in which authentication and
access control are required to prevent un-authorized users from
accessing such devices. This document proposes a PCP security extension
which enables PCP servers to authenticate their clients with Extensible
Authentication Protocol (EAP). The EAP messages are encapsulated within
PCP packets during transportation.</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>Disordered 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"/>. 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 does not create implicit mappings.</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 explicit mappings than it is in authorizing implicit
mappings.</t>
<t>For implementations that support the THIRD_PARTY Option (unless
they can meet the constraints outlined in Section 14.1.2.2).</t>
<t>For implementations that wish to support any deployment scenario
that does not meet the constraints described in Section 14.1.</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"/>.</t>
<t>Most of the terms used in this document are introduced in <xref
target="RFC6887"/>.</t>
<t>PCP Client: A PCP device (e.g., a host) which is responsible for
issuing PCP requests to a PCP server. In this document, a PCP client is
also a EAP peer <xref target="RFC3748"/>, and it is the responsibility
of a PCP client to provide the credentials when authentication is
required.</t>
<t>PCP Server: A PCP device (e.g., a NAT or a firewall) that implements
the server-side of the PCP protocol, via which PCP clients request and
manage explicit mappings. In this document, a PCP server is integrated
with an EAP authenticator <xref target="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.</t>
<t>PCP-Authentication (PCP-Auth) Session: A series of PCP message
exchanges transferred between a PCP client and a PCP server. The PCP
message involved within a session includes the PCP-Auth messages used to
perform EAP authentication, key distribution and session management, and
the common PCP messages secured with the keys distributed during
authentication. Each PCP-Auth session is assigned a distinctive Session
ID.</t>
<t>Session Partner: A PCP device involved within a PCP-Auth session.
Each PCP-Auth session has two session partners (a PCP server and a PCP
client).</t>
<t>Session Lifetime: The life period associated with a PCP-Auth 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 PCP-Auth
session, using an EAP key generating method (e.g., the one defined in
<xref target="RFC5448"/>).</t>
<t>PCP-Authentication (PCP-Auth) message: A PCP message containing an
Authentication OpCode. Particularly, a PCP-Auth message sent from a PCP
server to a PCP client is referred to as a PCP-Auth-Server, while
PCP-Auth message sent from a PCP client to a PCP server is referred to
as a PCP-Auth-Client. Therefore, a PCP-Auth-Server is actually a PCP
response message specified in <xref target="RFC6887"/>, and a
PCP-Auth-Client is a PCP request message. This document specifies an
option, the Authentication Tag Option for PCP Auth, to provide integrity
protection and message origin authentication for PCP-Auth messages.</t>
<t>Common PCP message: A PCP message which does not contain an
Authentication OpCode. This document specifies an option, the
Authentication Tag Option for Common PCP, 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 be beginning of a PCP-Auth session, a PCP client and a PCP
server need to exchange a series of PCP-Auth messages in order to
perform an EAP authentication process. Each PCP-Auth message is
attached with an Authentication OpCode and may optionally contain a
set of Options for various purposes (e.g., transporting authentication
messages and session managements). The Authentication OpCode consists
of two fields: Session ID and Sequence Number. The Session ID field is
used to identify the session to which the message belongs. The
sequence number field is used to detect the disorder or the
duplication occurred during packet delivery.</t>
<t>When a PCP client intends to proactively initiate a PCP-Auth
session with a PCP server, it sends a PCP-Auth-Initiation message (a
PCP-Auth-Client message with the result code "INITIATION") to the PCP
server. In the message, the Session ID and Sequence Number fields of
the Authentication OpCode are set as 0. The PCP client MAY also
optionally append a nonce option which consists of a random nonce with
the message.</t>
<t>After receiving the PCP-Auth-Initiation, if the PCP server agrees
to initiate a PCP-Auth session with the PCP client, it will reply with
a PCP-Auth-Server message which contains an EAP Identity Request, and
the result code field of this PCP-Auth-Server message is set as
AUTHENTICATION-REQUIRED. In addition, the server MUST assign a session
identifier which can distinctly identify this session, and fill the
identifier into the Session ID field of the Authentication OpCode in
the PCP-Auth-Server message. The Sequence Number field of the
Authentication OpCode is set as 0. If there is a nonce option in the
received PCP-Auth-Initiation message, the PCP-Auth-Server MUST be
attached with 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
the PCP-Auth-Server message. From now on, every PCP message within
this session will be attached with this session identifier. When
receiving a PCP-Auth message from an unknown session, a PCP device
MUST discard the message silently. If the PCP client intends to
simplify the authentication process, it MAY append an EAP Identity
Response message within the PCP-Auth-Initiation message so as to
inform the PCP server that it would like to perform EAP authentication
and skip the step of waiting for the EAP Identity Request.</t>
<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 can reply with a PCP-Auth-Server message to initiate a PCP-Auth
session. The result code field of this PCP-Auth-Server message is set
as AUTHENTICATION-REQUIRED. In addition, the PCP server MUST assign a
session ID for the session and transfer it within the PCP-Auth-Server
message. The Sequence Number field in the PCP-Auth-Server is set as 0.
In the PCP-Auth messages exchanged afterwards in this session, the
session ID MUST be used in order to help session partners distinguish
the messages within this session from those not within. When the PCP
client receives this initial PCP-Auth-Server message from the PCP
server, it can reply with a PCP-Auth-Client message or silently
discard the request message according to its local policies. In the
PCP-Auth-Client message, a nonce option which consists of a random
nonce MAY be appended. If so, in the next PCP-Auth-Server message, the
PCP sever MUST forward the nonce back within a nonce option.</t>
<t>In a PCP-Auth session, an EAP request message is transported within
a PCP-Auth-Server message, and an EAP answer message is transported
within a PCP-Auth-Client message. EAP relies on the underlying
protocol to provide reliable transmission; any disordered delivery or
loss of packets occurred during transportation must be detected and
addressed. Therefore, after sending out a PCP-Auth-Server message, the
PCP server will not send a new PCP-Auth-Server message until it
receives a PCP-Auth-Client message with a proper sequence number from
the PCP client, and vice versa. If a PCP device receives a PCP-Auth
message from its partner and cannot generate a EAP response within a
pre-specified period due to certain reasons (e.g., waiting for human
input to construct a EAP message or waiting for the additional
PCP-Auth messages in order to construct a complete EAP message), the
PCP device MUST reply with a PCP-Auth-Acknowledge message (PCP-Auth
messages with a Received Packet Option) to notify the packet has been
received. This approach not only can avoid un-necessarily
retransmission of the PCP-Auth message but also can guarantee the
reliable packet delivery in the conditions where a PCP device needs to
receive multiple PCP-Auth messages before generating an EAP
response.</t>
<t>In this approach, it is mandated for a PCP client and a PCP server
to perform a key-generating EAP method in authentication. Therefore,
after a successful authentication procedure, a Master Session Key
(MSK) will be generated. If the PCP client and the PCP server want to
generate a traffic key using the MSK, they need to agree upon a
Pseudo-Random Function (PRF) for the transport key derivation and a
MAC algorithm to provide data origin authentication for subsequent PCP
packets. In order to do this, the PCP server needs to append a set of
PRF Options and MAC Algorithm Options to the initial PCP-Auth-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. After receiving the
options, the PCP client selects the PRF and the MAC algorithm which it
would like to use, and then attach the associated PRF and MAC
Algorithm Options to the next PCP-Auth-Client message.</t>
<t>After the EAP authentication, the PCP server sends out a
PCP-Auth-Server message to indicate the EAP authentication and PCP
authorization results. If the EAP authentication succeeds, the result
code of the PCP-Auth-Server message is AUTHENTICATION-SUCCEED. In this
case, before sending out the PCP-Auth-Server message, the PCP server
MUST generate a PCP SA and use the derived transport key to generate a
digest for the message. The digest is transported within an
Authentication Tag Option for PCP Auth. A more detailed description of
generating the authentication data can be found in Section 7.1. In
addition, the PCP-Auth-Server MAY also contain a Session Lifetime
Option which indicates the life-time of the PCP-Auth session (i.e.,
the life-time of the MSK). After receiving the PCP-Auth-Server
message, the PCP client then needs to generate a PCP-Auth-Client
message as response. If the PCP client also authenticates the PCP
server, the result code of the PCP-Auth-Client is
AUTHENTICATION-SUCCEED. In addition, the PCP client needs to generate
a PCP SA and uses the derived traffic key to secure the message. From
then on, all the PCP messages within the session are secured with the
traffic key and the MAC algorithm specified in the PCP SA, unless a
re-authentication is performed.</t>
<t>If a PCP client/server cannot authenticate its session partner, the
device sends out a PCP-Auth message with the result code,
AUTHENTICATION-FAILED. If the EAP authentication succeeds but
Authorization fails, the device making the decision sends out a
PCP-Auth message with the result code, AUTHORIZATION-FAILED. In these
two cases, after the PCP-Auth message is sent out, the PCP-Auth
session MUST be terminated immediately.</t>
</section>
<section anchor="termination" title="Session Termination">
<t>A PCP-Auth session can be explicitly terminated by sending a
termination-indicating PCP-Auth message (a PCP-Auth message with a
result code "SESSION-TERMINATION" ) from either session partner. After
receiving a Termination-Indicating message from the session partner, a
PCP device MUST respond with a Termination-Indicating PCP-Auth message
and remove the PCP-Auth SA immediately. When the session partner
initiating the termination process receives the PCP-Auth message, it
will remove the associated PCP-Auth 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 (e.g., update the MSK and rollback the
sequence numbers, or extend the session life period) without
initiating a new PCP-Auth session.</t>
<t>When the PCP server would like to initiate a re-authentication, it
sends the PCP client a PCP-Auth-Server message. The result code of the
message is set to "RE-AUTHENTICATION", which indicates the message is
for an re-authentication process. If the PCP client would like to
start the re-authentication, it will send an PCP-Auth-Client message
to the PCP server, the result code of the PCP-Auth-Client message is
set to "RE-AUTHENTICATION". Then, the session partners exchange
PCP-Auth messages to transfer EAP messages for the re-authentication.
During the re-authentication procedure, the session partners protect
the integrity of PCP-Auth messages with the key and MAC algorithm
specified in the current PCP SA; the sequence numbers associated with
the packet will never be rolled back and keep increasing according to
Section 7.3.</t>
<t>If the EAP re-authentication succeeds, the result code of the last
PCP-Auth-Server is "AUTHENTICATION-SUCCEED". In this case, before
sending out the PCP-Auth-Server, the PCP server must update the SA and
use the new key to generate digests to protect the integrity and
authenticity of the PCP-Auth-Server and any subsequent PCP message. In
addition, the PCP-Auth-Server MAY be appended with a Session Lifetime
Option which indicates the new life-time of the PCP-Auth session.</t>
<t>If the EAP authentication fails, the result code of the last
PCP-Auth-Server is "AUTHENTICATION-FAILED". If the EAP authentication
succeeds but Authorization fails, the result code of the last
PCP-Auth-Server is "AUTHORIZATION-FAILED". In the latter two cases,
the PCP-Auth session MUST be terminated immediately after the last
PCP-Auth message exchange.</t>
</section>
</section>
<section title="PA Security Association">
<t>At the beginning of a PCP-Auth session, a session SHOULD generate a
PCP-Auth SA to maintain its state information during the session. The
parameters of a PCP-Auth SA are listed as follows:</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 PCP-Auth message</t>
<t>Sequence number for the next incoming PCP-Auth message</t>
<t>Sequence number for the next outgoing common PCP message
(included in the SA for PCP slient)</t>
<t>Sequence number for the next incoming common PCP message
(included in the SA for PCP slient)</t>
<t>Last outgoing message payload</t>
<t>Retransmission interval</t>
<t>MSK: The master session key generated by the EAP method.</t>
<t>MAC algorithm: The algorithm that the transport key should use to
generate digests for PCP messages.</t>
<t>Pseudo-random function: The pseudo random function negotiated in
the initial PCP-Auth-Server and PCP-Auth-Client exchange for the
transport key derivation</t>
<t>Transport key: the key derived from the MSK to provide integrity
protection and data origin authentication for the messages in the
PCP-Auth session. The life-time of the transport key SHOULD be
identical to the life-time of the session.</t>
<t>The nonce selected by the PCP client at the initiation of the
session.</t>
<t>Key ID: the 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>The 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>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 PCP-Auth-Client packet. If the PCP client does not select
one, this value is set as 0.</t>
<t>Key ID: The ID assigned for the traffic key.</t>
</list></t>
</section>
<section title="Result Code">
<t>This message use the result code field specified in the PCP headers
to transport the information for authentication and session management.
Particularly, the values of following result codes are specified.</t>
<t><list style="empty">
<t>TBD INITIATION</t>
<t>TBD AUTHENTICATION-REQUIRED</t>
<t>TBD AUTHENTICATION-FAILED</t>
<t>TBD AUTHENTICATION-SUCCEED</t>
<t>TBD AUTHORIZATION-FAILED</t>
<t>TBD SESSION-TERMINATION</t>
</list></t>
</section>
<section title="Packet Format ">
<section title="Packet Format of PCP Auth Messages">
<t>The format of PCP-Auth-Server messages is identical to the response
packet format specified in Section 7.2 of <xref
target="RFC6887"/>.</t>
<t>As illustrated in Figure 1, the PCP-Auth-Client messages use the
requester header specified in Section 7.1 of<xref target="RFC6887"/>.
The only difference is that eight reserved bits are used to transfer
the result codes (e.g., "INITIATION", "AUTHENTICATION-FAILED"). Other
fields in Figure 1 are described in Section 7.1 of <xref
target="RFC6887"/>.</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 1. PCP-Auth-Client message Format]]></artwork>
</figure>
</section>
<section title="Authentication OpCode ">
<t>The following figure illustrates the format of an authentication
OpCode: <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 PCP-Auth session
identifier.</t>
<t>Sequence Number: This field contains a 32-bit sequence number.
In this solution, a sequence number needs to be incremented on
every new (non-retransmission) outgoing packet in order to provide
ordering guarantee for PCP.</t>
</list></t>
<t/>
</section>
<section title="Nonce Option">
<t>Because the session identifier of PCP-Auth session is determined by
the PCP server, a PCP client does not know the session identifier
which will be used when it sends out a PCP-Auth-Initiation message. In
order to prevent an attacker from interrupting the authentication
process by sending off-line generated PCP-Auth-Server messages, the
PCP client needs to generate a random number as nonce in the
PCP-Auth-Initiation message. The PCP server will append the nonce
within the initial PCP-Auth-Server message. If the PCP-Auth-Server
message does not carry the correct nonce, the message will 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-Length: The length of the Nonce Option (in octet),
including the 4 octet fixed header and the variable length of the
authentication data.</t>
<t>Nonce: A random 32 bits number which is transported within a
PCC-Initiate message and the corresponding reply message from the
PCP server.</t>
</list></t>
</section>
<section title="Authentication Tag Option for Common PCP">
<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><list style="empty">
<t>Option-Length: The length of the Authentication Tag Option for
Common PCP (in octet), including the 12 octet fixed header and the
variable length of the authentication data.</t>
<t>Session ID: A 32-bit field used to indicates the identifier of
the session that the message belongs to and identifies the secret
key used to create the message digest appended to the PCP
message.</t>
<t>Sequence Number: This field contains a 32-bit sequence number.
In this solution, a sequence number needs to be incremented on
every new (non-retransmission) outgoing packet in order to provide
ordering guarantee for common PCP messages.</t>
<t>Key ID: The ID associated with the traffic key used to generate
authentication data. This field is filled with zero if MSK is
directly used to secure the message.</t>
<t>Authentication Data: A variable-length field that carries the
Message Authentication Code for the PCP packet. The generation of
the digest can be various according to the algorithms specified in
different PCP SAs. This field MUST end on a 32-bit boundary,
padded with 0's when necessary.</t>
</list></t>
</section>
<section title="Authentication Tag Option for PCP Auth Messages">
<t>This option is used to provide message authentication for PCP-Auth
messages. Compared with the Authentication Tag Option for Common PCP,
the session ID field and the sequence number field are removed because
such information is provided in 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | Reserved | Option-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data (Variable) |
~ ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
</figure><list style="empty">
<t>Option-Length: The length of the Authentication Tag Option for
PCP Auth (in octet), including the 12 octet fixed header and the
variable length of the authentication data.</t>
<t>Key ID: The ID associated with the traffic key used to generate
authentication data. This field is filled with zero if MSK is
directly used to secure the message.</t>
<t>Authentication Data: A variable-length field that carries the
Message Authentication Code for the PCP packet. The generation of
the digest can be various according to the algorithms specified in
different PCP SAs. This field MUST end on a 32-bit boundary,
padded with 0's when necessary.</t>
</list></t>
</section>
<section 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-Length: The length of the EAP Payload Option (in octet),
including the 4 octet fixed header and the variable length of the
EAP message.</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 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-Length: The length of the PRF Option (in octet), including
the 4 octet fixed header and the variable length of the EAP
message.</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="RFC4306"/><xref target="RFC4868"/>. A
PCP implementation MUST support PRF_HMAC_SHA2_256 (5).</t>
</section>
<section 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-Length: The length of the MAC Algorithm Option (in octet),
including the 4 octet fixed header and the variable length of the EAP
message.</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="RFC4306"/><xref target="RFC4868"/>.A PCP implementation MUST
support AUTH_HMAC_SHA2_256_128 (12).</t>
</section>
<section 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-Length: The length of the Session Lifetime Option (in
octet), including the 4 octet fixed header and the variable length of
the EAP message.</t>
<t>Session Lifetime: The life time of the PCP-Auth Session, which is
decided by the authorization result.</t>
</section>
<section title="Received Packet Option">
<t>This option is used in a PCP-Auth-Acknowledgement message to
indicate a packet 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-Length: The length of the Received Packet Option (in octet),
including the 4 octet fixed header and the variable length of the EAP
message.</t>
<t>Received Sequence Number: The sequence number of the last received
PCP packet.</t>
</section>
</section>
<section title="Processing Rules">
<t/>
<section title="Authentication Data Generation">
<t>If a PCP SA is generated as the result of a successful EAP
authentication process, every subsequent PCP message within the
session MUST carry an Authentication Tag Option which contains the
digest of the PCP message for data origin authentication and integrity
protection.</t>
<t>Before generating a digest for a PCP-Auth message, a device needs
to first locate the PCP SA according to the session identifier and
then get the traffic key. Then the device appends an 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 traffic 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 Authentication Tag Option) using
the traffic key and the associated MAC algorithm, and insert the
generated digest into the Authentication Data field.</t>
<t>Similar to generating a digest for a PCP-Auth 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
traffic key. Then the device appends the Authentication Tag Option for
common PCP at the end of the message. The length of the Authentication
Data field is decided by the MAC algorithm adopted in the session. The
device then use the corresponding values derived from the SA to fills
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 traffic key and the
associated MAC algorithm, and inputs the generated digest into the
Authentication Data field.</t>
</section>
<section title="Authentication Data Validation">
<t>When a device receives a common PCP packet with an Authentication
Tag Option for Common PCP, 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 key ID in the option) and the MAC
algorithm. If no proper SA or traffic key is found, the PCP packet
MUST be discarded silently. After storing the value of the
Authentication field of the Authentication Tag Option, the device
fills the Authentication field with zeros. Then, the device generates
a digest for the packet (including the PCP header and Authentication
Tag Option) with the transport key and the MAC algorithm found in the
first step. If the value of the newly generated digest is identical to
the stored one, the device can ensure that the packet has not been
tampered with, and the validation succeeds. Otherwise, the packet MUST
be discarded.</t>
<t>Similarly, when a device receives a PCP Auth packet with an
Authentication Tag Option for PCP Auth, 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 key ID in the option) and the
MAC algorithm. If no proper SA or traffic key is found, the PCP packet
MUST be discarded silently. After storing the value of the
Authentication field of the Authentication Tag Option, the device
fills the Authentication field with zeros. Then, the device generates
a digest for the packet (including the PCP header and Authentication
Tag Option) with the transport key and the MAC algorithm found in the
first step. If the value of the newly generated digest is identical to
the stored one, the device can ensure that the packet has not been
tampered with, and the validation succeeds. Otherwise, the packet MUST
be discarded.</t>
</section>
<section title="Retransmission Policies for PCP Auth Messages">
<t>Because EAP relies on the underlying protocols to provide reliable
transmission, after sending a PCP-Auth message, a PCP client/server
MUST NOT send out any subsequent messages until receiving an expect
PCP-Auth message (the PCP-Auth message with a proper sequence number)
from the peer. If no such a message is received in a certain period,
the PCP device will re-send the last message according to certain
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. </t>
<t>Note that the last PCP-Auth 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 PCP-Auth
messages. </t>
<t>When a device receives such a duplicate PCP-Auth message from its
session partner, it MUST try to answer it by sending the last outgoing
PCP-Auth message again. The rate of replying the duplicate PCP-Auth
messages MUST be limited.</t>
</section>
<section title="Sequence Numbers for PCP Auth Messages">
<t>PCP adopts UDP to transport signaling messages. As an un-reliable
transport protocol, UDP does not guarantee ordered packet delivery and
does not provide any protection from packet loss. In order to ensure
the EAP messages are exchanged in a reliable way, every PCP packet
exchanged during EAP authentication must carry an monotonically
increasing sequence number. During a PCP-Auth session, a PCP device
needs to maintain two sequence numbers for PCP-Auth messages, one for
incoming PCP-Auth messages and one for outgoing PCP-Auth messages.
When generating an outgoing PCP-Auth packet, the device attaches the
associated outgoing sequence number to the packet and increments the
sequence number maintained in the SA by 1. When receiving a PCP-Auth
packet from its session partner, the device will not accept it if the
sequence number carried in the packet does not match the incoming
sequence number the device maintains. After confirming that the
received packet is valid, the device increments the incoming sequence
number maintained in the SA by 1.</t>
<t>The above rules are not applied to PCP-Auth-Acknowledgement
messages (i.e., PCP-Auth messages containing a Received Packet
Option). A PCP-Auth-Acknowledgement message does not transport any EAP
message and only indicate at a PCP-Auth message is received.
Therefore, the reliable transmission of PCP-Auth-Acknowledgement
message does not have to be guaranteed. Therefore, when receiving or
sending out a PCP-Auth-Acknowledgement message, the device MUST not
increase the corresponding sequence number stored in the SA.
Otherwise, the lost of a PCP-Auth-Acknowledgement message during
transportation will cause the mismatching issues with the sequence
numbers.</t>
<t>Another exception is in the message retransmission scenarios. When
a device does not receive any response from its session partner in a
certain period, it needs to retransmit the last outgoing PCP-Auth
message with a limited rate. The duplicate messages and the original
message MUST use the identical sequence number. When the device
receives such a duplicate PCP-Auth message from its session partner,
it MUST try to answer it by sending the last outgoing PCP-Auth message
again. Note the rate of replying the duplicate PCP-Auth messages must
be limited. In such cases, the maintained incoming and outgoing
sequence numbers will not be affected by the message
retransmission.</t>
</section>
<section title="Sequence Numbers for Common PCP Messages">
<t>When transporting common PCP messages within a PCP-Auth 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 messages, the PCP device attaches the
outgoing sequence number for common PCP messages to the messages and
increments the sequence number maintained in the SA by 1.</t>
<t>When receiving a PCP packet from its session partner, the PCP
device will not accept it if the sequence number carried in the packet
is smaller than the incoming sequence number the server maintains.
This approach can protect the PCP server from replay attacks. After
confirming that the received packet is valid, the PCP server will use
the sequence number in the incoming packet to take place the incoming
sequence number for common PCP messages maintained in the SA.</t>
<t>Note that the sequence number in the incoming packet may not
exactly match the incoming sequence number maintained locally. In the
base PCP specification <xref target="RFC6887"/>, a PCP client may stop
retransmitting a PCP request without receiving any expected PCP answer
when the client is no longer interested in the PCP transaction. After
that, the PCP client will try to generate new PCP requests for other
purposes. In this case, the sequence number in the new request will be
larger than the incoming sequence number maintained in the PCP server.
</t>
</section>
<section title="MTU Considerations">
<t>EAP methods are responsible for MTU handling, so no special
facilities are required in this protocol to deal with MTU issues. If
an EAP message is too long for a single PCP-Auth message to transport,
it will be divided into multiple sections and transport them within
different PCP-Auth messages. Note that the receiver may not be able to
know what to do in the next step until receiving all the sections and
constructing the complete EAP message. In this case, in order to
guarantee reliable message transmission, after receiving a PCP-Auth
message, the receiver MUST reply with a PCP-Auth-Acknowledgement
message until all the sections have been received.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>TBD</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This section applies only to the in-band key management mechanism. It
will need to be updated if the WG choose to pursue the out-of-band key
management mechanism discussed above.</t>
<t>In this work, after a successful EAP authentication process performed
between two PCP devices, a MSK will be exported. The MSK can be used to
derive the transport keys to generate MAC digests for subsequent PCP
message exchanges. However, before a transport key has been generated,
the PCP-Auth messages exchanged within a PCP-Auth session have little
cryptographic protection, and if there is no already established
security channel between two session partners, these messages are
subject to man-in-the-middle attacks and DOS attacks. For instance, the
initial PCP-Auth-Server and PCP-Auth-Client exchange is vulnerable to
spoofing attacks as these messages are not authenticated and integrity
protected. In addition, because the PRF and MAC algorithms are
transported at this stage, an attacker may try to remove the PRF and MAC
options containing strong algorithms from the initial PCP-Auth-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 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
PCP-Auth-Server and PCP-Auth-Client exchanges. The choice of EAP method
is also very important. The selected EAP method must be resilient to the
attacks possibly in an insecure network environment, and the
user-identity confidentiality, protection against dictionary attacks,
and session-key establishment must be supported.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t/>
</section>
<section title="Change Log">
<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 traffic 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/>
</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>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.3748'?>
<?rfc include='reference.RFC.4306'?>
<?rfc include='reference.RFC.5191'?>
<?rfc include='reference.RFC.5448'?>
<?rfc include='reference.RFC.6887'?>
<?rfc include='reference.RFC.4868'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:22:32 |