| Network Working Group | M. Wasserman |
| Internet-Draft | S. Hartman |
| Intended status: Experimental | Painless Security |
| Expires: April 20, 2013 | D. Zhang |
| Huawei | |
| October 19, 2012 |
Port Control Protocol (PCP) Authentication Mechanism
draft-ietf-pcp-authentication-01.txt
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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 20, 2013.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:/⁠/⁠trustee.ietf.org/⁠license-⁠info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Using the Port Control Protocol (PCP) [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:
The mechanism described in this document meets the security requirements to address the Advanced Threat Model described in the base PCP specification [I-D.ietf-pcp-base]. This mechanism can be used to secure PCP in the following situations::
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
Most of the terms used in this document are introduced in [I-D.ietf-pcp-base].
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 [RFC3748], and it is the responsibility of a PCP client to provide the credentials when authentication is required.
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 [RFC3748]. Therefore, when necessary, a PCP server can verify the credentials provided by a PCP client and make an access control decision based on the authentication result.
PCP Authentication (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.
Session Lifetime: The life period associated with a PCP Auth session, which decided the lifetime of the current authorization given to the PCP client.
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.
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 [RFC5448]).
PCP Auth (PCP Authentication) message: A PCP message containing an Authentication OpCode for EAP authentication.
non PCP Auth message: A PCP message which is not a PCP Auth message.
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 [RFC5191] (with EAP). The WG will need to make a decision between these two approaches before this document can be completed.
Both approaches for key management could be used with the integrity protection mechanism and options described later in this document.
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.
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.
The first option can be further broken down into two apporaches: The PANA over PCP solution and the demultiplexing solution. For the first approach [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 [I-D.ohba-pcp-pana].
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.
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.
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.
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.
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.
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.
The message exchanges conveyed within an PCP Auth session is introduced in the remainder section.
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.
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.
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.
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.
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.
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).
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.
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.
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:
Particularly, the transport key is computed in the following way: Transport key = prf(MSK, "IETF PCP"| Session_ID, key ID), where:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following figure illustrates the format of an authentication Opcode:
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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) |
~ ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 [RFC4306].
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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.
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.
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.
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.
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.
The retransmission behavior is controlled and described by the following variables:
With each message transmission or retransmission, the sender sets RT according to the rules given below.
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:
RT = IRT
RT for each subsequent message retransmission is based on the previous value of RT (RTprev):
RT = (2+RAND) * RTprev
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:
if (RT > MRT)
RT = (1+RAND) * MRT
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.
EAP methods are responsible for MTU handling, so no special facilities are required in this protocol to deal with MTU issues.
TBD
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.
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.
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.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |