One document matched: draft-ietf-pcp-authentication-01.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-01.txt"
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="19" month="October" year="2012"/>
<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="I-D.ietf-pcp-base"/>, an IPv4 or IPv6 host can flexibly manage
the IP address mapping information on its network address translators
(NATs) and firewalls, and control their policies in processing incoming
and outgoing IP packets. Because NATs and firewalls both play important
roles in network security architectures, there are many situations in
which authentication and access control are required to prevent
un-authorized users from accessing such devices. This document proposes
a PCP security extension which enables PCP servers to authenticate their
clients with Extensible Authentication Protocol (EAP). The following
issues are considered in the design of this extension:</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></t>
<t>The mechanism described in this document meets the security
requirements to address the Advanced Threat Model described in the base
PCP specification <xref target="I-D.ietf-pcp-base"/>. 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="I-D.ietf-pcp-base"/>.</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 in order to
perform authentication, authorization, key distribution and secured PCP
communication. Each PCP Auth session is assigned a distinctive Session
ID. The PCP devices involved within a PCP Auth session are called
session partners. A PCP Auth session has two session partners.</t>
<t>Session Lifetime: The life period associated with a PCP Auth session,
which decided 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 Auth (PCP Authentication) message: A PCP message containing an
Authentication OpCode for EAP authentication.</t>
<t>non PCP Auth message: A PCP message which is not a PCP Auth
message.</t>
</section>
<section title="Separate vs. Inline Key Management">
<t>There is an open question in the working group regarding what
approach should be used for PCP key management. The precursor to this
document originally proposed an inline key management approach using EAP
directly over PCP. There was an alternative proposal on the list to
standardize a separate key management approach using PANA <xref
target="RFC5191"/> (with EAP). The WG will need to make a decision
between these two approaches before this document can be completed.</t>
<t>Both approaches for key management could be used with the integrity
protection mechanism and options described later in this document.</t>
</section>
<section title="Separate Key Management">
<t>The separate key management proposal involves running PANA between
the end-points to dynamically generate a security association, and then
using that security association to authenticate PCP message
exchanges.</t>
<t>In pricinpal, the PANA message can be transported either through the
PCP port or through an different port. The latter option has been
abandoned by the working group since it may impose unnecessary
management burdens and cause issues in securely binding the PCP session
to the PANA session initiation.</t>
<t>The first option can be further broken down into two apporaches: The
PANA over PCP solution and the demultiplexing solution. For the first
approach <xref target="I-D.ohba-pcp-pana-encap"/>, we would define an
AVP for PANA to indicate that the PANA session was being used for PCP
authentication, not for network access purposes. For the second
approach, we just re-use the PCP port to transport PANA message <xref
target="I-D.ohba-pcp-pana"/>.</t>
<t>The first approach introduces little change on PANA. Howerer, there
are criticisms about the existence of overlapping fields on the PANA and
PCP headers that need to be check for consistency.</t>
<t>Compared with the first approach, the second approach does not have
this problem. However, addition work needs to be done to help an PCP
implementation to distinguish a PANA message from a PCP message.</t>
<t>There are some functions of PANA which are not necessary for PCP. For
example, it would not be necessary for these servers to support IP
Address Reconfiguration and re-authentication. It may be possible to
address this problem by defining a subset of the PANA protocol that can
be run on PCP Servers if the same PANA server will not be used for
network access.</t>
<t>Once a secure session has been established using PANA, the Secure
OpCode option described in this draft could be used to associate PCP
requests with a particular PANA session.</t>
<t>Although a separate key management approach using PANA has been
discussed on the PCP mailing list, this approach would require further
documentation if the WG decides to pursue it.</t>
</section>
<section title="Protocol Details">
<section anchor="initiation" title="Session Initiation">
<t>To carry out an EAP authentication process between two PCP devices,
a set of PCP Auth messages need to be exchanged. A PCP Auth message
contains an Authentication OpCode and associated Options. The
Authentication OpCode consists of three fields: Session ID, Flag, and
Sequence Number. The Session ID field is used to identify the session
to which the message belongs. The Flag field indicates the type of the
PCP message. The sequence number field is used to detect the disorder
or the duplication occurred during packet delivery.</t>
<t>The message exchanges conveyed within an PCP Auth session is
introduced in the remainder section.</t>
<t>When a PCP client intends to initiate a PCP Auth session with a PCP
server, it sends a PCC-Initiation message to the PCP server. In the
message, the Session ID and Sequence Number fields of the
Authentication OpCode are set as 0; the I bit is set. The
PCC-Initiation message is also attached with a nonce option which
consists of a random nonce selected by the PCP client. The nonce will
be used by the PCP client to check the freshness of the initial
message from the PCP server. After receiving the PCC-Initiation, if
the PCP server would like to initiate a PCP Auth session, it will
reply with a PCP-Auth-Request which contains an EAP Identity Request.
The Sequence Number field in the PCP-Auth-Request is set as 0, and the
Session ID field MUST be filled with the session identifier assigned
by the PCP server for this session. The PCP-Auth-Request needs to be
attached with a nonce option which is learned from the PCP client.
From now on, every PCP Auth message within this session must be
attached with the session identifier. When receiving a PCP Auth
message from an unknown session, a PCP device MUST discard the message
silently. If the PCP client intends to simplify the authentication
process, it can append an EAP Identity Response message within the
PCC-Initiation request so as to inform the PCP server that it would
like to perform EAP authentication and skip the step of waiting for
the EAP Identity Request.</t>
<t>In the scenario where a PCP server receives a non-PA PCP message
from a PCP client which needs to be authenticated, the PCP server can
reply with a PCP-Auth-Request to initiate a PCP Auth session; the
result code field of the PCP-Auth-Request is set as
AUTHENTICATION-REQUIRED. In addition, the PCP server MUST assign a
session ID for the session and transfer it within the
PCP-Auth-Request. In the PCP Auth messages exchanged afterwards in
this session, the session ID MUST be appended. Therefore, in the
subsequent communication, the PCP client can distinguish the messages
in this session from those in other sessions through the PCP server IP
address and the session ID. When the PCP client receives the initial
PCP-Auth-Request message from the PCP server, it can reply with a
PCP-Auth-Answer message to continue the session or silently discard
the request message according to its local policies.</t>
<t>In a PCP Auth session, PCP-Auth-Request messages are sent from PCP
servers to PCP clients while PCP-Auth-Answer messages are only sent
from PCP clients to PCP servers. Correspondently, an EAP request
message MUST be transported within a PCP-Auth-Request message, and an
EAP answer message MUST be transported within a PCP-Auth-Answer
message. Particularly, when a PCP device receives a PCP-Auth-Request
or a PCP-Auth-Answer message from its partner, the PCP device needs to
reply with a PCP-Auth-Acknowledge message to indicate that the message
has been received. This solution is used to deal with the conditions
where the device cannot generate a response within a pre-specified
period due to certain reasons (e.g., waiting for human input to
construct a EAP message). Therefore, the partner does not have to
un-necessarily retransmit the PCP message.</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. On this occasion, the PCP server needs to append the initial
PCP-Auth-Request message with a set of PRF Options and MAC Algorithm
Options. Each PRF Option contains a PRF that the PCP server supports.
Similarly, each MAC Algorithm Option contains a MAC (Message
Authentication Code) algorithm that the PCP server supports. After
receiving the request, the PCP client selects a PRF and a MAC
algorithm which it would like to use, and sends back a PCP-Auth-Answer
with a PRF Option and a MAC Algorithm Option for the selected
algorithm.</t>
<t>The last PCP-Auth-Request message transported within a PCP Auth
session carries the EAP authentication and PCP authorization results.
The last PCP-Auth-Request and PCP-Auth-Answer messages MUST have the
'C' (Complete) bit set.</t>
<t>If the EAP authentication succeeds, the result code of the last
PCP-Auth-Request is AUTHENTICATION-SUCCESS. In this case, before
sending out the PCP-Auth-Request, the PCP server must derive a
transport key and use it to generate digests to protect the integrity
and authenticity of the PCP-Auth-Request and any subsequent PCP
message. Such digests are transported within Authentication Tag
Options. In addition, the PCP-Auth-Request needs to be appended with a
Session Lifetime Option which indicates the life-time of the PCP Auth
session (i.e., the life-time of the MSK).</t>
<t>If the EAP authentication fails, the result code of the last
PCP-Auth-Request is AUTHENTICATION-FAILED. If the EAP authentication
succeeds but Authorization fails, the result code of the last
PCP-Auth-Request is AUTHORIZATION-FAILED. In the latter two cases, the
PCP Auth session MUST be terminated immediately after the last PCP
authentication message exchange.</t>
</section>
<section anchor="termination" title="Session Termination">
<t>A PCP Auth session can be explicitly terminated by sending a
termination-indicating PCP Auth acknowledge message from either
session partner. After receiving a termination-indicating message from
the session partner, a PCP device MUST respond with a
termination-indicating PCP Auth Acknowledge message and remove the PCP
Auth SA immediately. When the session partner initiating the
termination process receives the acknowledge message, it will remove
the associated PCP Auth SA immediately.</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 message</t>
<t>Sequence number for the next incoming PCP message</t>
<t>Last outgoing message payload</t>
<t>Retransmission interval</t>
<t>MSK</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-Request and PCP-Auth-Answer 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>
</list></t>
<t>Particularly, the transport key is computed in the following way:
Transport key = prf(MSK, "IETF PCP"| Session_ID, 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>Key ID: The ID assigned for the traffic key</t>
</list></t>
</section>
<section title="Packet Format ">
<section title="Authentication OpCode Format">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I C R K T S E| Reserved | Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
</figure></t>
<t><list style="empty">
<t>Flags: The Flags field is two octets. The following bits are
assigned:</t>
</list></t>
<t><list style="empty">
<t/>
<t>I (Initiation): This bit is set in a PCC-Initiation
message.</t>
<t>C (Complete): If the message is the last PCP-Auth-Request or
PCP-Auth-Answer message in the session, this bit MUST be set. For
other messages, this bit MUST be cleared.</t>
<t>R (Request): This bit is set in a PCP-Auth-Request message, and
un-set in a PCP-Auth-Answer message.</t>
<t>K (acKnowledgement): This bit is set and only set in a
PCP-Auth-Acknowledgement message.</t>
<t>T (Termination): If this bit is set in a
PCP-Auth-Acknowledgement message, the message is used for
session-termination indication.</t>
<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>
<t>Result Code: This field is two octets. The following values are
defined:<list style="empty">
<t>1 AUTHENTICATION-REQUIRED</t>
<t>2 AUTHENTICATION-FAILED</t>
<t>3 AUTHENTICATION-SUCCESS</t>
<t>4 AUTHORIZATION-FAILED</t>
</list></t>
</list></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 PCC-Initiation message. In
order to prevent an attacker from interrupting the authentication
process by sending off-line generated PCP-Auth-Request messages, the
PCP client needs to generate a random number as nonce in the
PCC-Initiation message. The PCP server will append the nonce within
the initial PCP-Auth-Request message. If the PCP-Auth-Request message
does not carry the correct nonce, the message will be discarded
silently.</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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure><list style="empty">
<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">
<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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data (Variable) |
~ ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t><list style="empty">
<t>Option-Length: The length of the Authentication Tag Option (in
octet), including the 8 octet fixed header and the variable length
of the authentication data.</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>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>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><list style="empty">
<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"/>.</t>
</list></t>
</section>
<section title="Hash 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>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"/>.</t>
<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>Session Lifetime: The life time of the PCP Auth Session,
which is decided by the authorization result.</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 message, a device needs to
first select a traffic key in the session and append the
Authentication Tag Option at the end of the protected PCP message. The
length of the Authentication Data field is decided by the MAC
algorithm adopted in the session. The device then fills the Session ID
field and the PCP SA ID field, and sets the Authentication Data field
to 0. After this, the device generates a digest for the entire PCP
message (including the PCP header and Authentication Tag Option) with
the MAC algorithm and the selected traffic key, and input the
generated digest into the Authentication Data field.</t>
</section>
<section title="Authentication Data Validation">
<t>When a device receives a PCP packet with an Authentication Tag
Option, it needs to use the session ID transported in the option to
locate the proper SA, and then find the associated transport key
(using key ID) and the MAC algorithm. If no proper SA is found, the
PCP packet MUST be discarded silently. After storing the value of the
Authentication field of the Authentication Tag Option, the device
fills the Authentication field with zeros. Then, the device generates
a digest for the packet (including the PCP header and Authentication
Tag Option) with the transport key and the MAC algorithm found in the
first step. If the value of the newly generated digest is identical to
the stored one, the device can ensure that the packet has not been
tampered with, and the validation succeeds. Otherwise, the packet MUST
be discarded.</t>
</section>
<section title="Sequence Number">
<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, one for incoming packets and
one for outgoing packets. When generating an outgoing PCP packet, the
device attaches the outgoing sequence number to the packet and
increments the sequence number maintained in the SA by 1. When
receiving a PCP packet from its session partner, the device will not
accept it if the sequence number carried in the packet does not match
the incoming sequence number the device maintains.</t>
<t>After confirming that the received packet is valid, the device
increments the incoming sequence number maintained in the SA by 1.
However, the above rules are not applied to PCP-Auth-Acknowledgement
messages. When receiving or sending out a PCP-Auth-Acknowledgement
message, the device does not increase the corresponding sequence
number stored in the SA. Another exception is message retransmission.
When a device does not receive any response message from its session
partner in a certain period, it needs to retransmit the last sent
message with a limited rate. The duplicate messages and the original
message MUST use the identical sequence number. When the device
receives such duplicate messages from its session partner, it MUST try
to answer them by sending the last outgoing message with a limited
rate unless it has received another valid message with a larger
sequence number from its session. In such cases, the maintained
incoming and outgoing sequence numbers will not be affected by the
message retransmission.</t>
<t/>
</section>
<section title="Retransmission Policies">
<t>This work provides a retransmission mechanism for reliable PCP Auth
message delivery. The timer, the variables, and the rules used in this
mechanism are adopted from PANA.</t>
<t>The retransmission behavior is controlled and described by the
following variables:</t>
<t><list style="empty">
<t>RT: Retransmission timeout from the previous
(re)transmission</t>
<t>IRT: Base value for RT for the initial retransmission</t>
<t>MRC: Maximum retransmission count</t>
<t>MRT: Maximum retransmitting time interval</t>
<t>RAND: Randomization factor</t>
</list></t>
<t>With each message transmission or retransmission, the sender sets
RT according to the rules given below.</t>
<t>If RT expires before receiving any reply, the sender re-calculates
RT and retransmits the message. Each of the computations of a new RT
includes a randomization factor (RAND), which is a random number
chosen with a uniform distribution between -0.1 and +0.1. The
randomization factor is included to minimize the synchronization of
messages. The algorithm for choosing a random number does not need to
be cryptographically sound. The algorithm SHOULD produce a different
sequence of random numbers from each invocation. RT for the first
message retransmission is based on IRT:</t>
<t>RT = IRT</t>
<t>RT for each subsequent message retransmission is based on the
previous value of RT (RTprev):</t>
<t>RT = (2+RAND) * RTprev</t>
<t>MRT specifies an upper bound on the value of RT (disregarding the
randomization added by the use of RAND). If MRT has a value of 0,
there is no upper limit on the value of RT. Otherwise:</t>
<t>if (RT > MRT)</t>
<t>RT = (1+RAND) * MRT</t>
<t>MRC specifies an upper bound on the number of times a sender may
retransmit a message. Unless MRC is zero, the message exchange fails
once the sender has transmitted the message MRC times. In this case,
the sender needs to start a session termination process illustrated in
Section 3.2.</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.</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. This work does not exclude the possibility of using
the MSK to generate keys for different security protocols to enable
per-packet cryptographic protection. The methods of deriving the
transport key for the security protocols is out of scope of this
document.</t>
<t>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-Request and PCP-Auth-Answer exchange is vulnerable to spoofing
attacks as these messages are not authenticated and integrity protected.
In order to prevent very basic DOS attacks, a PCP device SHOULD generate
state information as little as possible in the initial PCP-Auth-Request
and PCP-Auth-Answer exchanges. The choice of EAP method is also very
important. The selected EAP method must be resilient to the attacks
possibly in an insecure network environment, and the user-identity
confidentiality, protection against dictionary attacks, and session-key
establishment must be supported.</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-Request or a
PCP-Auth-Answer message from its partner the PCP device needs to
reply with a PCP-Auth-Acknowledge message to indicate that the
message has been received.</t>
<t>Add the support of fragmenting EAP messages.</t>
</list></t>
</section>
<section title="Changes from wasserman-pcp-authentication-00 to -01">
<t><list style="symbols">
<t>Editorial changes, added use cases to introduction.</t>
</list></t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.ietf-pcp-base'?>
<?rfc include='reference.RFC.3748'?>
<?rfc include='reference.RFC.4306'?>
<?rfc include='reference.RFC.5191'?>
<?rfc include='reference.RFC.5448'?>
<?rfc include='reference.I-D.ohba-pcp-pana-encap'?>
<?rfc include='reference.I-D.ohba-pcp-pana'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:21:06 |