One document matched: draft-ietf-pcp-authentication-00.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-00.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="27" month="June" 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 (PCC): A PCP device (e.g., a host) which is responsible
for issuing PCP requests to a PCP server. In this document, a PCC is
also a EAP peer <xref target="RFC3748"/>, and it is the responsibility
of a PCC to provide the credentials when authentication is required.</t>
<t>PCP Server (PCS): A PCP device (e.g., a NAT or a firewall) that
implements the server-side of the PCP protocol, via which PCCs request
and manage explicit mappings. In this document, a PCS is integrated with
an EAP authenticator <xref target="RFC3748"/>. Therefore, when
necessary, a PCS can verify the credentials provided by a PCC 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 PCC and a PCS in order to perform authentication,
authorization, key distribution and secured PCP communication. Each PA
session is assigned a distinctive Session ID. The PCP devices involved
within a PA session are called session partners. A typical PA session
has two session partners.</t>
<t>Session Lifetime: The life period associated with a PA session, which
decided the lifetime of the current authorization given to the PCC.</t>
<t>PCP Security Association (PCP SA): A PCP security association is
formed between a PCC and a PCS by sharing cryptographic keying material
and associated context. The formed duplex security association is used
to protect the bidirectional PCP signaling traffic between the PCC and
PCS.</t>
<t>Master Session Key (MSK): A key derived by the partners of a PA
session, using a EAP key generating method (e.g., the one defined in
<xref target="RFC5448"/>) .</t>
<t>PA (PCP for Authentication) message: A PCP message containing an
Authentication OpCode for EAP authentication.</t>
<t>non-PA message: A PCP message which is not a PA 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>
For this approach we would define an AVP for PANA to
indicate that the PANA session was being used for PCP
authentication, not for network access purposes.
</t>
<t>
A PANA server would be implemented on each PCP server that
support authenticated requests, or another mechanism would
need to be specified to locate a PANA server that can be used
for PCP-related PANA requests. It may be possible to define 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. For
example, it would not be necessary for these servers to
support IP Address Reconfiguration.
</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.
Some discussion may be needed on how the PCP session will
be securely bound to the PANA session initiation.
</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="Inline Key Management">
<t>
The inline key management approach is described in this
document in the sections <xref target="initiation"/>
and <xref target="termination"/>.
</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 PA messages need to be exchanged. A PA
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 PA session is
introduced in the remainder section.
</t>
<t>
When a PCC intends to initiate a PA session with a PCS, it
sends a PCC-Initiation message to the PCS. 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 PCC to
tolerate off-line attacks. After receiving the
PCC-Initiation, if the PCS would like to initiate a PA
session, it will reply with a PA-Request which contains an
EAP Identity Request. The Sequence Number field in the
PA-Request is set as 0, and the Session ID field MUST be
filled with the session identifier assigned by the PCS for
this session. The PA-Request also needs to be attached with
a nonce option which is learned from the PCC. Form now on,
every PA message within this session must be attached with
the session identifier. When receiving a PA message from an
unknown session, a PCP device MUST discard the message
silently. If the PCC intends to simplify the authentication
process, it can append an EAP Identity Response message
within the PCC-Initiation request so as to inform the PCS
that it would like to perform EAP authentication andskip
over the step of waiting for the EAP Identity Request.
</t>
<t>
In the scenario where a PCS receives a non-PA PCP message
from a PCC which needs to be authenticated, the PCS can
reply with a PA-Request to initiate a PA session; the result
code field of the PA-Request is set as
AUTHENTICATION-REQUIRED. In addition, the PCS MUST assign a
session ID for the session and transfer it within the
PA-Request. In the PA messages exchanged afterwards in this
session, the session ID MUST be appended. Therefore, in the
subsequent communication, the PCC can distinguish the
messages in this session from those in other sessions
through the PCS IP address and the session ID. When the PCC
receives the initial PA-Request message from the PCS, it can
reply with a PA-Answer message to continue the session or
silently discards the request message according to its local
policies.
</t>
<t>
In a PA session, PA-Request messages are sent from PCSs to
PCCs while PA-Answer messages are only sent from PCCs to
PCSs. Correspondently, an EAP request messages MUST be
transported within a PA-Request message, and an EAP answer
messages MUST be transported within a PA-Answer
message. Particularly, when a PCP device receives a
PA-Request or a PA-Answer message from its partner, the PCP
device needs to reply with a PA-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 retransfer the PCP message.
</t>
<t>
In this work, it is mandated for a PCC and a PCS 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 PCC and the PCS
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 PCS needs to append the initial PA-Request message with
a set of PRF Options and MAC Algorithm Options. Each PRF
Option contains a PRF that the PCS supports. Similarly, each
MAC Algorithm Option contains a MAC (Message Authentication
Code) algorithm that the PCS supports. After receiving the
request, the PCC selects a PRF and a MAC algorithm which it
would like to use, and sends back a PA-Answer with a PRF
Option and a MAC Algorithm Option for the selected
algorithms.
</t>
<t>
The last PA-Request message transported within a PA session
carries the EAP authentication and PCP authorization
results. The last PA-Request and PA-Answer messages MUST
have their the 'C' (Complete) bit set.
</t>
<t>
If the EAP authentication succeeds, the result code of the
last PA-Request is AUTHENTICATION-SUCCESS. In this case,
before sending out the PA-Request, the PCS must derive a
transport key and use it to generate digests to protect the
integrity and authenticity of the PA-Request and any
subsequent PCP message. Such digests are transported within
Authentication Tag Options. In addition, the PA-Request
needs to be appended with a Session Lifetime Option which
indicates the life time of the PA session (i.e., the life
time of the MSK).
</t>
<t>
If the EAP authentication fails, the result code of the last
PA-Request is AUTHENTICATION-FAILED. If the EAP
authentication successes but Authorization fails, the result
code of the last PA-Request is AUTHORIZATION-FAILED. In the
latter two cases, the PA session MUST be terminated
immediately after the last PCP authentication message
exchange.
</t>
</section>
<section anchor="termination" title="Session Termination">
<t>
A PA session can be explicitly terminated by sending a
termination-indicating PA acknowledge message from either
session partner. After receiving a termination-indicating
message from the session partner, a PCP device MUST response
with a termination-indicating PA Acknowledge message and
remove the PA SA immediately. When the session partner
initiating the termination process receives the acknowledge
message, it will remove the associated PA SA
immediately.
</t>
</section>
</section>
<section title="PA Security Association">
<t>
At the beginning a PA session, a session SHOULD generate a PA
SA to maintain its state information during the session. The
parameters of a PA SA is listed as follows:
</t>
<t><list style="symbols">
<t>IP address and UDP port number of the PCC</t>
<t>IP address and UDP port number of the PCS</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 PA-Request and PA-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 PA 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | 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>
<figure>
<artwork><![CDATA[
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I C R A K T S E r r r r r r r r|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<list style="empty">
<t><list style="symbols">
<t>I (Initiation): This bit is set in a PCC-Initiation
message.</t>
<t>C (Complete): If the message is the last PA-Request or
PA-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 PA-Request message.</t>
<t>A (Answer): This bit is set in a PA-Answer message.</t>
<t>K (acKnowledgement): This bit is set and only set in a
PA-Acknowledgement message.</t>
<t>T (Termination): If this bit is set in a PA-Acknowledgement
message, the message is used for session-termination
indication.</t>
</list>
</t>
<t>Session ID: This field contains a 32-bit PA 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.Following result code
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>
Question: Would it be possible to remove this option from
the PCP authentication draft, and use the nonce from the
main PCP header instead?
</t>
<t>
Because the session identifier of PA session is determined
by the PCS, a PCS 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
PA-Request messages, the PCS needs to generate a random
number as nonce in the PCC-Initiation message. The PCS will
append the nonce within the initial PA-Request message. if
the PA-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 correspondent reply message from the
PCS.</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 a MSK. This filed 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 period of the PA 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 an 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
as 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 out 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 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 during the transportation. The validation
successes. Otherwise, the packet MUST be discarded.</t>
</section>
<section title="Sequence Number">
<t>PCP adopts UDP to transport signaling messages. As an un-reliable
transporting protocol, UDP does not guarantee the 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 carries an
monotonically increased sequence number. During a PA 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 PA-Acknowledgement
messages. When receiving or sending out a PA-Acknowledgement message,
the device does not inicrease the correspondent 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 tries 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 PA
message delivery. The timer, the variables, and the rules used in this
mechanism is mostly brought 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
include 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 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-Request and
PA-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 PA-Request and PA-Answer exchanges. The choice of EAP
method is also very important. The selected EAP method must be
resilient to the attacks possibly occurred in a 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>This document was written using the xml2rfc tool described in RFC
2629 <xref target="RFC2629"/>.</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 PA message between the
PCC and PCS. When a PCC 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 PA-Request or a
PA-Answer message from its partner the PCP device needs to reply
with a PA-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'?>
&rfc2629;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:35:00 |