Internet Engineering Task Force (IETF) M. Cullen
Request for Comments: 7652 S. Hartman
Updates: 6887 Painless Security
Category: Standards Track D. Zhang
ISSN: 2070-1721
T. Reddy
Cisco
September 2015
Internet Engineering Task Force (IETF) M. Cullen
Request for Comments: 7652 S. Hartman
Updates: 6887 Painless Security
Category: Standards Track D. Zhang
ISSN: 2070-1721
T. Reddy
Cisco
September 2015
Port Control Protocol (PCP) Authentication Mechanism
端口控制协议（PCP）身份验证机制
Abstract
摘要
An IPv4 or IPv6 host can use the Port Control Protocol (PCP) to flexibly manage the IP address-mapping and port-mapping information on Network Address Translators (NATs) or firewalls to facilitate communication with remote hosts. However, the uncontrolled generation or deletion of IP address mappings on such network devices may cause security risks and should be avoided. In some cases, the client may need to prove that it is authorized to modify, create, or delete PCP mappings. This document describes an in-band authentication mechanism for PCP that can be used in those cases. The Extensible Authentication Protocol (EAP) is used to perform authentication between PCP devices.
IPv4或IPv6主机可以使用端口控制协议（PCP）灵活管理网络地址转换器（NAT）或防火墙上的IP地址映射和端口映射信息，以便于与远程主机通信。但是，在此类网络设备上不受控制地生成或删除IP地址映射可能会导致安全风险，应避免。在某些情况下，客户机可能需要证明其有权修改、创建或删除PCP映射。本文档描述了可在这些情况下使用的PCP带内身份验证机制。可扩展身份验证协议（EAP）用于在PCP设备之间执行身份验证。
This document updates RFC 6887.
本文件更新了RFC 6887。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7652.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7652.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 6
3.1.1. Authentication Triggered by the Client . . . . . . . 6
3.1.2. Authentication Triggered by the Server . . . . . . . 7
3.1.3. Authentication Using EAP . . . . . . . . . . . . . . 8
3.2. Recovery from Lost PA Session . . . . . . . . . . . . . . 10
3.3. Session Termination . . . . . . . . . . . . . . . . . . . 11
3.4. Session Re-authentication . . . . . . . . . . . . . . . . 11
4. PA Security Association . . . . . . . . . . . . . . . . . . . 12
5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Packet Format of PCP Auth Messages . . . . . . . . . . . 14
5.2. Opcode-Specific Information of AUTHENTICATION Opcode . . 16
5.3. NONCE Option . . . . . . . . . . . . . . . . . . . . . . 16
5.4. AUTHENTICATION_TAG Option . . . . . . . . . . . . . . . . 17
5.5. PA_AUTHENTICATION_TAG Option . . . . . . . . . . . . . . 18
5.6. EAP_PAYLOAD Option . . . . . . . . . . . . . . . . . . . 19
5.7. PRF Option . . . . . . . . . . . . . . . . . . . . . . . 19
5.8. MAC_ALGORITHM Option . . . . . . . . . . . . . . . . . . 20
5.9. SESSION_LIFETIME Option . . . . . . . . . . . . . . . . . 20
5.10. RECEIVED_PAK Option . . . . . . . . . . . . . . . . . . . 21
5.11. ID_INDICATOR Option . . . . . . . . . . . . . . . . . . . 21
6. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 22
6.1. Authentication Data Generation . . . . . . . . . . . . . 22
6.2. Authentication Data Validation . . . . . . . . . . . . . 23
6.3. Retransmission Policies for PA Messages . . . . . . . . . 24
6.4. Sequence Numbers for PCP Auth Messages . . . . . . . . . 25
6.5. Sequence Numbers for Common PCP Messages . . . . . . . . 26
6.6. MTU Considerations . . . . . . . . . . . . . . . . . . . 26
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
7.1. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.2. AUTHENTICATION_TAG . . . . . . . . . . . . . . . . . . . 28
7.3. PA_AUTHENTICATION_TAG . . . . . . . . . . . . . . . . . . 29
7.4. EAP_PAYLOAD . . . . . . . . . . . . . . . . . . . . . . . 29
7.5. PRF . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.6. MAC_ALGORITHM . . . . . . . . . . . . . . . . . . . . . . 30
7.7. SESSION_LIFETIME . . . . . . . . . . . . . . . . . . . . 30
7.8. RECEIVED_PAK . . . . . . . . . . . . . . . . . . . . . . 30
7.9. ID_INDICATOR . . . . . . . . . . . . . . . . . . . . . . 31
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1. Normative References . . . . . . . . . . . . . . . . . . 32
9.2. Informative References . . . . . . . . . . . . . . . . . 33
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 6
3.1.1. Authentication Triggered by the Client . . . . . . . 6
3.1.2. Authentication Triggered by the Server . . . . . . . 7
3.1.3. Authentication Using EAP . . . . . . . . . . . . . . 8
3.2. Recovery from Lost PA Session . . . . . . . . . . . . . . 10
3.3. Session Termination . . . . . . . . . . . . . . . . . . . 11
3.4. Session Re-authentication . . . . . . . . . . . . . . . . 11
4. PA Security Association . . . . . . . . . . . . . . . . . . . 12
5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Packet Format of PCP Auth Messages . . . . . . . . . . . 14
5.2. Opcode-Specific Information of AUTHENTICATION Opcode . . 16
5.3. NONCE Option . . . . . . . . . . . . . . . . . . . . . . 16
5.4. AUTHENTICATION_TAG Option . . . . . . . . . . . . . . . . 17
5.5. PA_AUTHENTICATION_TAG Option . . . . . . . . . . . . . . 18
5.6. EAP_PAYLOAD Option . . . . . . . . . . . . . . . . . . . 19
5.7. PRF Option . . . . . . . . . . . . . . . . . . . . . . . 19
5.8. MAC_ALGORITHM Option . . . . . . . . . . . . . . . . . . 20
5.9. SESSION_LIFETIME Option . . . . . . . . . . . . . . . . . 20
5.10. RECEIVED_PAK Option . . . . . . . . . . . . . . . . . . . 21
5.11. ID_INDICATOR Option . . . . . . . . . . . . . . . . . . . 21
6. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 22
6.1. Authentication Data Generation . . . . . . . . . . . . . 22
6.2. Authentication Data Validation . . . . . . . . . . . . . 23
6.3. Retransmission Policies for PA Messages . . . . . . . . . 24
6.4. Sequence Numbers for PCP Auth Messages . . . . . . . . . 25
6.5. Sequence Numbers for Common PCP Messages . . . . . . . . 26
6.6. MTU Considerations . . . . . . . . . . . . . . . . . . . 26
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
7.1. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.2. AUTHENTICATION_TAG . . . . . . . . . . . . . . . . . . . 28
7.3. PA_AUTHENTICATION_TAG . . . . . . . . . . . . . . . . . . 29
7.4. EAP_PAYLOAD . . . . . . . . . . . . . . . . . . . . . . . 29
7.5. PRF . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.6. MAC_ALGORITHM . . . . . . . . . . . . . . . . . . . . . . 30
7.7. SESSION_LIFETIME . . . . . . . . . . . . . . . . . . . . 30
7.8. RECEIVED_PAK . . . . . . . . . . . . . . . . . . . . . . 30
7.9. ID_INDICATOR . . . . . . . . . . . . . . . . . . . . . . 31
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1. Normative References . . . . . . . . . . . . . . . . . . 32
9.2. Informative References . . . . . . . . . . . . . . . . . 33
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
Using the Port Control Protocol (PCP) [RFC6887], an application can flexibly manage the IP address-mapping information on its network address translators (NATs) and firewalls and can 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 unauthorized users from accessing such devices. This document defines a PCP security extension that enables PCP servers to authenticate their clients with the Extensible Authentication Protocol (EAP). The EAP messages are encapsulated within PCP messages during transmission.
使用端口控制协议（PCP）[RFC6887]，应用程序可以灵活地管理其网络地址转换器（NAT）和防火墙上的IP地址映射信息，并可以控制其处理传入和传出IP数据包的策略。由于NAT和防火墙在网络安全体系结构中都扮演着重要角色，因此在许多情况下，需要身份验证和访问控制来防止未经授权的用户访问此类设备。本文档定义了一个PCP安全扩展，使PCP服务器能够使用可扩展身份验证协议（EAP）对其客户端进行身份验证。EAP消息在传输期间封装在PCP消息中。
The following issues are considered in the design of this extension:
本扩建工程的设计考虑了以下问题：
o Loss of EAP messages during transmission.
o 传输过程中EAP消息丢失。
o Reordered delivery of EAP messages.
o 重新排序EAP消息的传递。
o Generation of transport keys.
o 传输密钥的生成。
o Integrity protection and data origin authentication for PCP messages.
o PCP消息的完整性保护和数据源身份验证。
o Algorithm agility.
o 算法灵活性。
The mechanism described in this document meets the security requirements to address the Advanced Threat Model described in the base PCP specification [RFC6887]. This mechanism can be used to secure PCP in the following situations:
本文档中描述的机制满足基本PCP规范[RFC6887]中描述的高级威胁模型的安全要求。此机制可用于在以下情况下保护PCP：
o On security infrastructure equipment, such as corporate firewalls, that does not create implicit mappings for specific traffic.
o 在安全基础设施设备（如公司防火墙）上，不会为特定流量创建隐式映射。
o On equipment (such as Carrier-Grade NATs (CGNs) or service provider firewalls) that serves multiple administrative domains and do not have a mechanism to securely partition traffic from those domains.
o 在为多个管理域提供服务的设备（如运营商级NAT（CGN）或服务提供商防火墙）上，并且没有安全地将流量与这些域划分的机制。
o For any implementation that wants to be more permissive in authorizing applications to create mappings for successful inbound communications destined to machines located behind a NAT or a firewall.
o 对于任何希望在授权应用程序创建映射以成功发送到位于NAT或防火墙后面的机器的入站通信方面更为宽松的实现。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Most of the terms used in this document are introduced in [RFC6887].
本文件中使用的大多数术语在[RFC6887]中介绍。
PCP client: A PCP software instance that is responsible for issuing PCP requests to a PCP server. In this document, a PCP client is also an EAP peer [RFC3748], and it is the responsibility of a PCP client to provide the credentials when authentication is required.
PCP客户端：负责向PCP服务器发出PCP请求的PCP软件实例。在本文档中，PCP客户端也是EAP对等方[RFC3748]，PCP客户端有责任在需要身份验证时提供凭据。
PCP server: A PCP software instance that resides on the PCP-controlled device that receives PCP requests from the PCP client and creates appropriate state in response to that request. In this document, a PCP server is integrated with an EAP authenticator [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服务器：驻留在PCP控制设备上的PCP软件实例，该设备接收来自PCP客户端的PCP请求，并创建相应的状态以响应该请求。在本文档中，PCP服务器与EAP验证器集成[RFC3748]。因此，必要时，PCP服务器可以验证PCP客户端提供的凭据，并基于认证结果做出访问控制决策。
PCP-Authentication (PA) session: A series of PCP message exchanges transferred between a PCP client and a PCP server. The PCP messages that are part of a given session include the PA messages used to perform EAP authentication, key distribution, and session management, as well as the common PCP messages secured with the keys distributed during authentication. Each PA session is assigned a distinctive Session ID.
PCP身份验证（PA）会话：在PCP客户端和PCP服务器之间传输的一系列PCP消息交换。作为给定会话的一部分的PCP消息包括用于执行EAP认证、密钥分发和会话管理的PA消息，以及由认证期间分发的密钥保护的公共PCP消息。每个PA会话都分配了一个独特的会话ID。
Session partner: A PCP implementation involved in a PA session. Each PA session has two session partners (a PCP server and a PCP client).
会话伙伴：PA会话中涉及的PCP实现。每个PA会话有两个会话伙伴（一个PCP服务器和一个PCP客户端）。
PCP device: A PCP client or a PCP server.
PCP设备：PCP客户端或PCP服务器。
Session lifetime: The lifetime associated with a PA session. The session lifetime of the PA session decides the lifetime of the current authorization given to the PCP client.
会话生存期：与PA会话关联的生存期。PA会话的会话生存期决定授予PCP客户端的当前授权的生存期。
PA Security Association (PCP SA): An association 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.
PA安全关联（PCP SA）：通过共享加密密钥材料和关联上下文，在PCP客户端和PCP服务器之间形成的关联。形成的双工安全关联用于保护PCP客户端和PCP服务器之间的双向PCP信令流量。
Master Session Key (MSK): A key derived by the partners of a PA session, using an EAP key-generating method (e.g., the method defined in [RFC5448]).
主会话密钥（MSK）：PA会话的伙伴使用EAP密钥生成方法（例如，[RFC5448]中定义的方法）派生的密钥。
PCP-Authentication (PA) message: A PCP message containing an AUTHENTICATION Opcode. Specifically, a PA message sent from a PCP server to a PCP client is referred to as a PA-Server message, while a PA message sent from a PCP client to a PCP server is referred to as a PA-Client message. Therefore, a PA-Server message is actually a PCP response message as specified in [RFC6887], and a PA-Client message is a PCP request message. This document specifies an option -- the PA_AUTHENTICATION_TAG option defined in Section 5.5 for PCP authentication -- to provide integrity protection and message origin authentication for PA messages.
PCP身份验证（PA）消息：包含身份验证操作码的PCP消息。具体地说，从PCP服务器发送到PCP客户端的PA消息称为PA服务器消息，而从PCP客户端发送到PCP服务器的PA消息称为PA客户端消息。因此，PA服务器消息实际上是[RFC6887]中指定的PCP响应消息，PA客户端消息是PCP请求消息。本文件规定了一个选项——第5.5节中定义的PCP认证PA_认证标签选项——为PA消息提供完整性保护和消息源认证。
Common PCP message: A PCP message that does not contain an AUTHENTICATION Opcode. This document specifies an AUTHENTICATION_TAG option to provide integrity protection and message origin authentication for the common PCP messages.
公共PCP消息：不包含身份验证操作码的PCP消息。本文档指定了一个身份验证标签选项，用于为常见PCP消息提供完整性保护和消息源身份验证。
At the beginning of a PA session, a PCP client and a PCP server need to exchange a series of PA messages in order to perform an EAP authentication process. Each PA message MUST contain an AUTHENTICATION Opcode and may optionally contain a set of options for various purposes (e.g., transporting authentication messages and session management). The Opcode-specific information in an AUTHENTICATION Opcode consists of two fields: Session ID and Sequence Number. The Session ID field is used to identify the PA session to which the message belongs. The Sequence Number field is used to detect whether reordering or duplication occurred during message delivery.
在PA会话开始时，PCP客户端和PCP服务器需要交换一系列PA消息以执行EAP身份验证过程。每个PA消息必须包含一个身份验证操作码，并且可以选择包含一组用于各种目的的选项（例如，传输身份验证消息和会话管理）。身份验证操作码中的操作码特定信息由两个字段组成：会话ID和序列号。会话ID字段用于标识消息所属的PA会话。序列号字段用于检测邮件传递期间是否发生了重新排序或重复。
When a PCP client intends to proactively initiate a PA session with a PCP server, it sends a PA-Initiation message (a PA-Client message with the result code INITIATION) to the PCP server. Section 5.1 updates the PCP request message format with result codes for the PCP authentication mechanism. In the Opcode-specific information of the message, the Session ID and Sequence Number fields are set to zero. The PA-Client message MUST also contain a NONCE option (defined in Section 5.3) that consists of a random nonce.
当PCP客户端打算主动启动与PCP服务器的PA会话时，它会向PCP服务器发送PA启动消息（带有启动结果代码的PA客户端消息）。第5.1节使用PCP认证机制的结果代码更新PCP请求消息格式。在消息的操作码特定信息中，会话ID和序列号字段设置为零。PA客户端消息还必须包含由随机NONCE组成的NONCE选项（在第5.3节中定义）。
After receiving the PA-Initiation message, if the PCP server agrees to initiate a PA session with the PCP client, it will reply with a PA-Server message that contains an EAP request, and the Result Code field of this PA-Server message is set to AUTHENTICATION_REQUEST. In addition, the server MUST assign a unique session identifier to
接收到PA启动消息后，如果PCP服务器同意启动与PCP客户端的PA会话，它将使用包含EAP请求的PA服务器消息进行回复，并且此PA服务器消息的结果代码字段设置为AUTHENTICATION_request。此外，服务器必须为服务器分配唯一的会话标识符
distinctly identify this session and insert the identifier into the Session ID field in the Opcode-specific information of the PA-Server message. The Sequence Number field of the message is set to zero. The PA-Server message MUST contain a NONCE option so as to send the nonce value back. The nonce will then be used by the PCP client to check the freshness of this message. Subsequent PCP messages within this PA session MUST contain this session identifier.
明确标识此会话，并将标识符插入PA服务器消息的操作码特定信息中的会话ID字段。消息的序列号字段设置为零。PA服务器消息必须包含NONCE选项，以便将NONCE值发回。然后，PCP客户端将使用nonce来检查此消息的新鲜度。此PA会话中的后续PCP消息必须包含此会话标识符。
PCP PCP
client server
|-- PA-Initiation ------------------------------->|
| (Seq=0, rc=INITIATION, Session ID=0) |
| |
|<-- PA-Server -----------------------------------|
| (Seq=0, Session ID=X, EAP request, |
| rc=AUTHENTICATION_REQUEST) |
| |
|-- PA-Client ----------------------------------->|
| (Seq=1, Session ID=X, EAP response, |
| rc=AUTHENTICATION_REPLY) |
| |
|<-- PA-Server -----------------------------------|
| (Seq=1, Session ID=X, EAP request, |
| rc=AUTHENTICATION_REQUEST) |
PCP PCP
client server
|-- PA-Initiation ------------------------------->|
| (Seq=0, rc=INITIATION, Session ID=0) |
| |
|<-- PA-Server -----------------------------------|
| (Seq=0, Session ID=X, EAP request, |
| rc=AUTHENTICATION_REQUEST) |
| |
|-- PA-Client ----------------------------------->|
| (Seq=1, Session ID=X, EAP response, |
| rc=AUTHENTICATION_REPLY) |
| |
|<-- PA-Server -----------------------------------|
| (Seq=1, Session ID=X, EAP request, |
| rc=AUTHENTICATION_REQUEST) |
In the scenario where a PCP server receives a common PCP request message from a PCP client that needs to be authenticated, the PCP server rejects the request with an AUTHENTICATION_REQUIRED error code and can reply with an unsolicited PA-Server message to initiate a PA session. The Result Code field of this PA-Server message is set to AUTHENTICATION_REQUEST. In addition, the PCP server MUST assign a Session ID for the session and transfer it within the PA-Server message. The Sequence Number field in the PA-Server message is set to zero. If the PCP client retries the common request before EAP authentication is successful, then it will receive an AUTHENTICATION_REQUIRED error code from the PCP server. In subsequent PA messages exchanged during this session, the Session ID will be used in order to help session partners distinguish the messages within this session from those not within it. When the PCP client receives this initial PA-Server message from the PCP server, it can reply with a PA-Client message or silently discard the request message, according to its local policies. In the PA-Client message, a NONCE option that consists of a random nonce MAY be appended. If so, in the next PA-Server message, the PCP server MUST forward the nonce back within a NONCE option.
在PCP服务器从需要认证的PCP客户端接收公共PCP请求消息的场景中，PCP服务器使用认证所需的错误代码拒绝请求，并可以使用未经请求的PA服务器消息进行回复以启动PA会话。此PA服务器消息的结果代码字段设置为AUTHENTICATION_REQUEST。此外，PCP服务器必须为会话分配会话ID，并在PA服务器消息中传输。PA服务器消息中的序列号字段设置为零。如果PCP客户端在EAP身份验证成功之前重试公共请求，则它将从PCP服务器接收到需要身份验证的错误代码。在此会话期间交换的后续PA消息中，将使用会话ID来帮助会话伙伴区分此会话内的消息和不在会话内的消息。当PCP客户机从PCP服务器接收到此初始PA服务器消息时，它可以根据其本地策略使用PA客户机消息进行回复或以静默方式放弃请求消息。在PA客户端消息中，可以附加由随机NONCE组成的NONCE选项。如果是这样，在下一个PA服务器消息中，PCP服务器必须在nonce选项内将nonce转发回。
PCP PCP
client server
|-- Common PCP request -------------------------->|
| |
|<- Common PCP response --------------------------|
| (rc=AUTHENTICATION_REQUIRED) |
| |
|<-- PA-Server -----------------------------------|
| (Seq=0, Session ID=X, EAP request, |
| rc=AUTHENTICATION_REQUEST) |
| |
|-- PA-Client ----------------------------------->|
| (Seq=0, Session ID=X, EAP response, |
| rc=AUTHENTICATION_REPLY) |
| |
|<-- PA-Server -----------------------------------|
| (Seq=1, Session ID=X, EAP request, |
| rc=AUTHENTICATION_REQUEST) |
PCP PCP
client server
|-- Common PCP request -------------------------->|
| |
|<- Common PCP response --------------------------|
| (rc=AUTHENTICATION_REQUIRED) |
| |
|<-- PA-Server -----------------------------------|
| (Seq=0, Session ID=X, EAP request, |
| rc=AUTHENTICATION_REQUEST) |
| |
|-- PA-Client ----------------------------------->|
| (Seq=0, Session ID=X, EAP response, |
| rc=AUTHENTICATION_REPLY) |
| |
|<-- PA-Server -----------------------------------|
| (Seq=1, Session ID=X, EAP request, |
| rc=AUTHENTICATION_REQUEST) |
In a PA session, an EAP request message is transported within a PA-Server message and an EAP response message is transported within a PA-Client message. EAP relies on the underlying protocol to provide reliable transmission; any reordered delivery or loss of packets occurring during transmission must be detected and addressed. Therefore, after sending out a PA-Server message, the PCP server will not send a new PA-Server message in the same PA session until it receives a PA-Client message with a proper sequence number from the PCP client, and vice versa. If a PCP client receives a PA message containing an EAP request and for some reason cannot generate an EAP response immediately (e.g., waiting for human input in order to construct an EAP message, or waiting for the additional PA messages in order to assemble a complete EAP message from fragmented packets), the PCP device MUST reply with a PA-Acknowledgement message (a PA message with a RECEIVED_PAK option) to indicate that the message has been received. This approach not only can avoid unnecessary retransmission of the PA message but also can guarantee reliable message delivery in conditions where a PCP device needs to receive multiple PA messages carrying the fragmented EAP request before generating an EAP response. The number of EAP messages exchanged between the PCP client and PCP server depends on the EAP method used for authentication.
在PA会话中，EAP请求消息在PA服务器消息中传输，EAP响应消息在PA客户端消息中传输。EAP依靠底层协议提供可靠的传输；在传输过程中发生的任何重新排序的传送或数据包丢失都必须被检测和处理。因此，在发送PA服务器消息之后，PCP服务器将不会在同一PA会话中发送新的PA服务器消息，直到它从PCP客户端接收到具有正确序列号的PA客户端消息，反之亦然。如果PCP客户端接收到包含EAP请求的PA消息，并且由于某种原因无法立即生成EAP响应（例如，等待人工输入以构建EAP消息，或等待其他PA消息以从碎片数据包组装完整的EAP消息），PCP设备必须回复PA确认消息（带有RECEIVED_-PAK选项的PA消息），以指示消息已被接收。该方法不仅可以避免PA消息的不必要的重传，而且还可以在PCP设备需要在生成EAP响应之前接收携带分段EAP请求的多个PA消息的情况下保证可靠的消息传递。PCP客户端和PCP服务器之间交换的EAP消息数量取决于用于身份验证的EAP方法。
In this approach, a PCP client and a PCP server MUST perform a key-generating EAP method in authentication. Specifically, a PCP authentication implementation MUST support Extensible Authentication Protocol Tunneled Transport Layer Security (EAP-TTLS) [RFC5281] and
在这种方法中，PCP客户端和PCP服务器必须在身份验证中执行密钥生成EAP方法。具体而言，PCP身份验证实现必须支持可扩展身份验证协议隧道传输层安全性（EAP-TTLS）[RFC5281]和
SHOULD support the Tunnel Extensible Authentication Protocol (TEAP) [RFC7170]. Therefore, after a successful authentication procedure, a Master Session Key (MSK) will be generated. If the PCP client and the PCP server want to generate a transport key using the MSK, they need to agree upon a Pseudorandom Function (PRF) for the transport key derivation and a Message Authentication Code (MAC) algorithm to provide data origin authentication for subsequent PCP messages. In order to do this, the PCP server needs to append a set of PRF options and MAC_ALGORITHM options to the initial PA-Server message. Each PRF option contains a PRF that the PCP server supports, and each MAC_ALGORITHM option contains a MAC algorithm that the PCP server supports. Moreover, in the first PA-Server message, the server MAY also attach an ID_INDICATOR option (defined in Section 5.11) to direct the client to choose correct credentials. After receiving the options, the PCP client MUST select the PRF and the MAC algorithm that it would like to use; it then MUST add the associated PRF and MAC Algorithm options to the next PA-Client message.
应支持隧道可扩展身份验证协议（TEAP）[RFC7170]。因此，在成功的身份验证过程之后，将生成主会话密钥（MSK）。如果PCP客户端和PCP服务器希望使用MSK生成传输密钥，则它们需要商定用于传输密钥派生的伪随机函数（PRF）和用于为后续PCP消息提供数据源身份验证的消息身份验证码（MAC）算法。为此，PCP服务器需要向初始PA服务器消息附加一组PRF选项和MAC_算法选项。每个PRF选项包含PCP服务器支持的PRF，每个MAC_算法选项包含PCP服务器支持的MAC算法。此外，在第一条PA服务器消息中，服务器还可以附加一个ID_指示符选项（在第5.11节中定义），以指示客户端选择正确的凭据。在收到选项后，PCP客户端必须选择它想要使用的PRF和MAC算法；然后，它必须将相关的PRF和MAC算法选项添加到下一个PA客户端消息中。
After the EAP authentication, the PCP server sends out a PA-Server message to indicate the EAP authentication and PCP authorization results. If the EAP authentication succeeds, the result code of the PA-Server message is AUTHENTICATION_SUCCEEDED. In this case, before sending out the PA-Server message, the PCP server MUST update the PCP SA with the MSK and transport key and MUST use the derived transport key to generate a digest for the message. The digest is transported within a PA_AUTHENTICATION_TAG option for PCP Auth. A more detailed description of generating the authentication data can be found in Section 6.1. In addition, the PA-Server message MUST also contain a SESSION_LIFETIME option (defined in Section 5.9) that indicates the lifetime of the PA session (i.e., the lifetime of the MSK). After receiving the PA-Server message, the PCP client then needs to generate a PA-Client message in response. If the PCP client also authenticates the PCP server, the result code of the PA-Client message is AUTHENTICATION_SUCCEEDED. In addition, the PCP client needs to update the PCP SA with the MSK and transport key, and it uses the derived transport key to secure the message. From then on, all the PCP messages within the session are secured with the transport key and the MAC algorithm specified in the PCP SA. The first secure PA-Client message from the client MUST include the set of PRF and MAC_ALGORITHM options received from the PCP server. The PCP server determines if the set of algorithms conveyed by the client matches the set it had initially sent, to detect an algorithm downgrade attack. If the server detects a downgrade attack, then it MUST send a PA-Server message with result code DOWNGRADE_ATTACK_DETECTED and terminate the session. If the PCP client sends a common PCP request within the PA session without an AUTHENTICATION_TAG option, then the PCP server rejects the request by returning an AUTHENTICATION_REQUIRED error code.
在EAP身份验证之后，PCP服务器发送PA服务器消息以指示EAP身份验证和PCP授权结果。如果EAP身份验证成功，则PA服务器消息的结果代码为“身份验证成功”。在这种情况下，在发送PA服务器消息之前，PCP服务器必须使用MSK和传输密钥更新PCP SA，并且必须使用派生的传输密钥生成消息摘要。摘要在PCP Auth的PA_AUTHENTICATION_标记选项中传输。有关生成认证数据的更详细说明，请参见第6.1节。此外，PA服务器消息还必须包含会话_生存期选项（在第5.9节中定义），该选项指示PA会话的生存期（即MSK的生存期）。收到PA服务器消息后，PCP客户端需要生成PA客户端消息作为响应。如果PCP客户端也对PCP服务器进行身份验证，则PA客户端消息的结果代码为“身份验证成功”。此外，PCP客户端需要使用MSK和传输密钥更新PCP SA，并使用派生的传输密钥保护消息。从那时起，会话中的所有PCP消息都使用PCP SA中指定的传输密钥和MAC算法进行保护。来自客户端的第一条安全PA客户端消息必须包括从PCP服务器接收的一组PRF和MAC_算法选项。PCP服务器确定客户端传送的算法集是否与其最初发送的算法集匹配，以检测算法降级攻击。如果服务器检测到降级攻击，则必须发送一条PA服务器消息，其中包含检测到的结果代码“降级攻击”，并终止会话。如果PCP客户端在PA会话中发送公共PCP请求，而没有身份验证标签选项，则PCP服务器通过返回身份验证所需的错误代码来拒绝该请求。
If a PCP client/server cannot authenticate its session partner, the device sends out a PA message with the result code AUTHENTICATION_FAILED. If the EAP authentication succeeds but authorization fails, the device making the decision sends out a PA message with the result code AUTHORIZATION_FAILED. In these two cases, after the PA message is sent out, the PA session MUST be terminated immediately. It is possible for independent PCP clients on the host to create multiple PA sessions with the PCP server.
如果PCP客户端/服务器无法对其会话伙伴进行身份验证，则设备将发送一条PA消息，结果代码为“身份验证失败”。如果EAP身份验证成功但授权失败，则做出决定的设备将发送一条PA消息，结果代码为authorization_FAILED。在这两种情况下，PA消息发出后，必须立即终止PA会话。主机上的独立PCP客户端可以与PCP服务器创建多个PA会话。
If a PCP server resets or loses the PCP SA due to reboot, power failure, or any other reason, then it sends an unsolicited ANNOUNCE response, as explained in Section 14.1.3 of [RFC6887], to the PCP client. Upon receiving the ANNOUNCE response with an anomalous Epoch Time, the PCP client deduces that the server may have lost state. The ANNOUNCE is either bogus (an attack), legitimate, or not seen by the client. These three cases are described below:
如果PCP服务器由于重新启动、电源故障或任何其他原因重置或丢失PCP SA，则会向PCP客户端发送未经请求的公告响应，如[RFC6887]第14.1.3节所述。在接收到具有异常历元时间的通告响应时，PCP客户端推断服务器可能已丢失状态。公告要么是伪造的（攻击），要么是合法的，要么是客户端看不到的。这三种情况描述如下：
o The PCP client sends an integrity-protected unicast ANNOUNCE request to the PCP server to see whether the PCP server has indeed lost state or an attacker has sent the ANNOUNCE response.
o PCP客户端向PCP服务器发送完整性保护的单播公告请求，以查看PCP服务器是否确实已失去状态，或者攻击者是否已发送公告响应。
* If an integrity-protected success response is received from the PCP server, then the PCP client determines that the PCP server has not lost the PA session, and the unsolicited ANNOUNCE response was sent by an attacker.
* 如果从PCP服务器接收到完整性保护的成功响应，则PCP客户端将确定PCP服务器没有丢失PA会话，并且未经请求的公告响应是由攻击者发送的。
* If the PCP server responds to the ANNOUNCE request with an UNKNOWN_SESSION_ID error code, then the PCP client MUST initiate full EAP authentication with the PCP server, as explained in Section 3.1.1. After EAP authentication is successful, the PCP client updates the PCP SA and issues new common PCP requests to recreate any lost mapping state.
* 如果PCP服务器以未知会话ID错误代码响应公告请求，则PCP客户端必须启动PCP服务器的完整EAP身份验证，如第3.1.1节所述。EAP身份验证成功后，PCP客户端更新PCP SA并发出新的公共PCP请求以重新创建任何丢失的映射状态。
o In a scenario where the PCP server has lost the PCP SA but did not inform the PCP client, if the PCP client sends an integrity-protected PCP request, then the PCP server rejects the request with an UNKNOWN_SESSION_ID error code. The PCP client then initiates full EAP authentication with the PCP server, as explained in Section 3.1.1, and updates the PCP SA after successful authentication.
o 在PCP服务器丢失PCP SA但未通知PCP客户端的情况下，如果PCP客户端发送完整性保护的PCP请求，则PCP服务器将拒绝该请求，并返回未知的会话ID错误代码。然后，PCP客户端启动PCP服务器的完整EAP身份验证，如第3.1.1节所述，并在成功身份验证后更新PCP SA。
If the PCP client resets or loses the PCP SA due to reboot, power failure, or any other reason and sends a common PCP request, then the PCP server rejects the request with an AUTHENTICATION_REQUIRED error code. The PCP client MUST authenticate with the PCP server and, after EAP authentication is successful, retry the common PCP request
如果PCP客户端由于重新启动、电源故障或任何其他原因重置或丢失PCP SA，并发送一个公共PCP请求，则PCP服务器将拒绝该请求，并显示一个验证所需的错误代码。PCP客户端必须与PCP服务器进行身份验证，EAP身份验证成功后，重试公共PCP请求
with an AUTHENTICATION_TAG option. The PCP server MUST update the PCP SA after successful EAP authentication.
带有身份验证标签选项。PCP服务器必须在EAP身份验证成功后更新PCP SA。
A PA session can be explicitly terminated by either session partner. A PCP server may explicitly request termination of the session by sending an unsolicited termination-indicating PA response (a PA response with a result code of SESSION_TERMINATED). Upon receiving a termination-indicating message, the PCP client MUST respond with a termination-indicating PA message and MUST then remove the associated PCP SA. To accommodate packet loss, the PCP server MAY transmit the termination-indicating PA response up to ten times (with an appropriate Epoch Time value in each to reflect the passage of time between transmissions), provided that (1) the interval between the first two notifications is at least 250 ms and (2) each interval between subsequent notifications at least doubles.
PA会话可以由任一会话伙伴显式终止。PCP服务器可以通过发送指示PA响应的未经请求的终止（具有会话_终止的结果代码的PA响应）来明确请求终止会话。接收到终止指示消息后，PCP客户端必须响应终止指示PA消息，然后必须移除相关PCP SA。为了适应分组丢失，PCP服务器可以发送指示PA响应的终止多达十次（每个发送中具有适当的历元时间值以反映发送之间的时间流逝），前提是（1）前两个通知之间的间隔至少为250 ms和（2）后续通知之间的每个间隔至少加倍。
A PCP client may explicitly request termination of the session by sending a termination-indicating PA request (a PA request with a result code of SESSION_TERMINATED). After receiving a termination-indicating message from the PCP client, a PCP server MUST respond with a termination-indicating PA message and remove the PCP SA immediately. When the PCP client receives the termination-indicating PA response, it MUST remove the associated PCP SA immediately.
PCP客户端可以通过发送指示PA请求的终止（具有会话_终止的结果代码的PA请求）来明确请求终止会话。从PCP客户端接收到终止指示消息后，PCP服务器必须响应终止指示PA消息，并立即移除PCP SA。当PCP客户端接收到指示PA响应的终止时，它必须立即删除关联的PCP SA。
A session partner may choose to perform EAP re-authentication if it would like to update the PCP SA without initiating a new PA session. For example, a re-authentication procedure could be triggered for the following reasons:
如果会话伙伴希望在不启动新PA会话的情况下更新PCP SA，则可以选择执行EAP重新认证。例如，可能出于以下原因触发重新身份验证过程：
o The session lifetime needs to be extended.
o 会话生存期需要延长。
o The sequence number is going to reach the maximum value. Specifically, when the sequence number reaches 2**32 - 2**16, the session partner MUST trigger re-authentication.
o 序列号将达到最大值。具体来说，当序列号达到2**32-2**16时，会话伙伴必须触发重新认证。
When the PCP server would like to initiate a re-authentication, it sends the PCP client a PA-Server message. The result code of the message is set to RE-AUTHENTICATION, which indicates that the message is for a re-authentication process. If the PCP client would like to start the re-authentication, it will send a PA-Client message to the PCP server, with the result code of the PA-Client message set to RE-AUTHENTICATION. Then, the session partners exchange PA messages to transfer EAP messages for the re-authentication. During the re-authentication procedure, the session partners protect the
当PCP服务器想要启动重新身份验证时，它会向PCP客户端发送一条PA服务器消息。消息的结果代码设置为重新身份验证，这表示消息用于重新身份验证过程。如果PCP客户端希望启动重新身份验证，它将向PCP服务器发送PA客户端消息，PA客户端消息的结果代码设置为重新身份验证。然后，会话伙伴交换PA消息以传输EAP消息以进行重新身份验证。在重新身份验证过程中，会话伙伴保护
integrity of PA messages with the key and MAC algorithm specified in the current PCP SA; the sequence numbers associated with the message will continue to keep increasing as specified in Section 6.4. The result code for a PA-Server message carrying an EAP request will be set to AUTHENTICATION_REQUIRED, and a PA-Client message carrying an EAP response will be set to AUTHENTICATION_REPLY.
具有当前PCP SA中指定的密钥和MAC算法的PA消息的完整性；按照第6.4节的规定，与信息相关的序列号将继续增加。携带EAP请求的PA服务器消息的结果代码将设置为AUTHENTICATION_REQUIRED，携带EAP响应的PA客户端消息将设置为AUTHENTICATION_REPLY。
If the EAP re-authentication succeeds, the result code of the last PA-Server message is AUTHENTICATION_SUCCEEDED. In this case, before sending out the PA-Server message, the PCP server MUST update the SA and use the new key to generate a digest for the PA-Server message and subsequent PCP messages. In addition, the PA-Server message MUST be appended with a SESSION_LIFETIME option that indicates the new lifetime of the PA session. PA and PCP message sequence numbers must also be reset to zero.
如果EAP重新身份验证成功，则最后一条PA服务器消息的结果代码为“身份验证成功”。在这种情况下，在发送PA服务器消息之前，PCP服务器必须更新SA并使用新密钥为PA服务器消息和后续PCP消息生成摘要。此外，PA服务器消息必须附加一个会话\ U生存期选项，该选项指示PA会话的新生存期。PA和PCP消息序列号也必须重置为零。
If the EAP authentication fails, the result code of the last PA-Server message is AUTHENTICATION_FAILED. If the EAP authentication succeeds but authorization fails, the result code of the last PA-Server message is AUTHORIZATION_FAILED. In the latter two cases, the PA session MUST be terminated immediately after the last PA message exchange. If for some unknown reason re-authentication is not performed and the session lifetime has expired, then the PA session MUST be terminated immediately.
如果EAP身份验证失败，则最后一条PA服务器消息的结果代码为“身份验证失败”。如果EAP身份验证成功但授权失败，则最后一条PA服务器消息的结果代码为authorization_FAILED。在后两种情况下，PA会话必须在最后一次PA消息交换后立即终止。如果由于某种未知原因未执行重新身份验证且会话生存期已过期，则必须立即终止PA会话。
During re-authentication, the session partners can also exchange common PCP messages in parallel. The common PCP messages MUST be protected with the current SA until the new SA has been generated. The sequence of EAP messages exchanged for re-authentication will not change, regardless of the PCP device triggering re-authentication. If the PCP server receives a re-authentication request from the PCP client after the PCP server itself had sent a re-authentication request, then it should discard its request and respond to the re-authentication request from the PCP client.
在重新身份验证期间，会话伙伴还可以并行交换公共PCP消息。在生成新SA之前，必须使用当前SA保护公共PCP消息。无论PCP设备触发重新身份验证，为重新身份验证交换的EAP消息序列都不会改变。如果PCP服务器在PCP服务器本身发送重新身份验证请求后从PCP客户端接收到重新身份验证请求，则应放弃其请求并响应来自PCP客户端的重新身份验证请求。
At the beginning of a new PA session, each PCP device must create and initialize state information for a new PA Security Association (PCP SA) to maintain its state information for the duration of the PA session. The parameters of a PCP SA are as follows:
在新PA会话开始时，每个PCP设备必须创建并初始化新PA安全关联（PCP SA）的状态信息，以在PA会话期间维护其状态信息。PCP SA的参数如下所示：
o IP address and UDP port number of the PCP client.
o PCP客户端的IP地址和UDP端口号。
o IP address and UDP port number of the PCP server.
o PCP服务器的IP地址和UDP端口号。
o Session identifier.
o 会话标识符。
o Sequence number for the next outgoing PA message.
o 下一个传出PA消息的序列号。
o Sequence number for the next incoming PA message.
o 下一个传入PA消息的序列号。
o Sequence number for the next outgoing common PCP message.
o 下一个传出公共PCP消息的序列号。
o Sequence number for the next incoming common PCP message.
o 下一条传入公共PCP消息的序列号。
o Last outgoing message payload.
o 最后传出的消息有效负载。
o Retransmission interval.
o 重传间隔。
o The Master Session Key (MSK) generated by the EAP method.
o 由EAP方法生成的主会话密钥（MSK）。
o The MAC algorithm that the transport key should use to generate digests for PCP messages.
o 传输密钥用于生成PCP消息摘要的MAC算法。
o The pseudorandom function negotiated in the initial PA-Server and PA-Client message exchange for the transport key derivation.
o 在初始PA服务器和PA客户端消息交换中协商的伪随机函数，用于传输密钥派生。
o The transport key derived from the MSK to provide integrity protection and data origin authentication for the messages in the PA session. The lifetime of the transport key SHOULD be identical to the lifetime of the session.
o 从MSK派生的传输密钥，用于为PA会话中的消息提供完整性保护和数据源身份验证。传输密钥的生存期应与会话的生存期相同。
o The nonce selected by the PCP client at the initiation of the session.
o PCP客户端在会话启动时选择的nonce。
o The key ID associated with the transport key.
o 与传输密钥关联的密钥ID。
Specifically, the transport key is computed in the following way: transport key = prf(MSK, "IETF PCP" || Session ID || Nonce || key ID), where:
具体而言，传输密钥按以下方式计算：传输密钥=prf（MSK，“IETF PCP”| | | | | | | | |密钥ID），其中：
o prf is the pseudorandom function assigned in the PRF option (Section 5.7).
o prf是在prf选项中指定的伪随机函数（第5.7节）。
o MSK is the master session key generated by the EAP method.
o MSK是EAP方法生成的主会话密钥。
o "IETF PCP" is the ASCII code representation of the non-null-terminated string (excluding the double quotes around it).
o “IETF PCP”是非空终止字符串（不包括其周围的双引号）的ASCII码表示形式。
o '||' is the concatenation operator.
o “| |”是串联运算符。
o Session ID is the ID of the session from which the MSK is derived.
o 会话ID是从中派生MSK的会话的ID。
o Nonce is the nonce selected by the client and transported in the initial PA-Client message.
o Nonce是客户端选择并在初始PA客户端消息中传输的Nonce。
o Key ID is the ID assigned for the transport key.
o 密钥ID是为传输密钥分配的ID。
The format of the PA-Server message is identical to the response message format specified in Section 7.2 of [RFC6887]. The result code for a PA-Server message carrying an EAP request MUST be set to AUTHENTICATION_REQUEST.
PA服务器消息的格式与[RFC6887]第7.2节中规定的响应消息格式相同。携带EAP请求的PA服务器消息的结果代码必须设置为AUTHENTICATION_request。
This document updates the Reserved field (see Figure 1) in the Request header specified in Section 7.1 of [RFC6887] to carry Opcode-specific data.
本文档更新了[RFC6887]第7.1节中指定的请求头中的保留字段（见图1），以携带特定于操作码的数据。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 2 |R| Opcode | Reserved |Opcode-specific|
| | | | | data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Lifetime (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| PCP Client's IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Opcode-specific information :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: (optional) PCP Options :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 2 |R| Opcode | Reserved |Opcode-specific|
| | | | | data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Lifetime (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| PCP Client's IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Opcode-specific information :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: (optional) PCP Options :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Request Packet Format
图1：请求包格式
The PA-Client messages (as shown in Figure 2) use the Request header specified in Figure 1. The Opcode-specific data is used to transfer the result codes (e.g., INITIATION, AUTHENTICATION_FAILED). Other fields in Figure 2 are described in Section 7.1 of [RFC6887]. The result code for a PA-Client message carrying an EAP response MUST be set to AUTHENTICATION_REPLY.
PA客户端消息（如图2所示）使用图1中指定的请求头。操作码特定数据用于传输结果码（例如，启动、身份验证失败）。图2中的其他字段在[RFC6887]的第7.1节中进行了描述。携带EAP响应的PA客户端消息的结果代码必须设置为AUTHENTICATION_REPLY。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 2 |R| Opcode | Reserved | Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Lifetime (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| PCP Client's IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Opcode-specific information :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: (optional) PCP Options :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 2 |R| Opcode | Reserved | Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Lifetime (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| PCP Client's IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Opcode-specific information :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: (optional) PCP Options :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: PA-Client Message Format
图2:PA客户端消息格式
The Requested Lifetime field of a PA-Client message and the Lifetime field of a PA-Server message are both set to zero on transmission and ignored on reception.
PA客户端消息的请求生存期字段和PA服务器消息的生存期字段在传输时都设置为零，在接收时被忽略。
The following diagram shows the format of the Opcode-specific information for the AUTHENTICATION Opcode.
下图显示了身份验证操作码的操作码特定信息的格式。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Session ID: This field contains a 32-bit PA session identifier.
会话ID：此字段包含32位PA会话标识符。
Sequence Number: This field contains a 32-bit sequence number. A sequence number needs to be incremented on every new (non-retransmission) outgoing PA message in order to provide an ordering guarantee for PA messages.
序列号：此字段包含32位序列号。每一个新的（非重传）传出PA消息都需要增加一个序列号，以便为PA消息提供排序保证。
Because the session identifier of a PA session is determined by the PCP server, a PCP client does not know the session identifier that will be used when it sends out a PA-Initiation message. In order to prevent an attacker from interrupting the authentication process by sending spoofed PA-Server messages, the PCP client needs to generate a random number as a nonce in the PA-Initiation message. The PCP server will append the nonce within the initial PA-Server message. If the PA-Server message does not carry the correct nonce, the message MUST be silently discarded.
由于PA会话的会话标识符由PCP服务器确定，因此PCP客户端不知道在发送PA启动消息时将使用的会话标识符。为了防止攻击者通过发送伪造的PA服务器消息来中断身份验证过程，PCP客户端需要在PA启动消息中生成一个随机数作为nonce。PCP服务器将在初始PA服务器消息中附加nonce。如果PA服务器消息未包含正确的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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Code: 4.
选项代码：4。
Reserved: 8 bits. MUST be set to zero on transmission and MUST be ignored on reception.
保留：8位。传输时必须设置为零，接收时必须忽略。
Option-Length: 4 octets.
选项长度：4个八位字节。
Nonce: A random 32-bit number that is transported within a PA-Initiation message and the corresponding reply message from the PCP server.
Nonce：在PA启动消息和来自PCP服务器的相应回复消息中传输的随机32位数字。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | Reserved | Option-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data (Variable) |
~ ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | Reserved | Option-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data (Variable) |
~ ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Because there is no authentication Opcode in common PCP messages, the authentication tag for common PCP messages needs to carry the Session ID and Sequence Number.
因为公共PCP消息中没有身份验证操作码，所以公共PCP消息的身份验证标签需要携带会话ID和序列号。
Option Code: 5.
选项代码：5。
Reserved: 8 bits. MUST be set to zero on transmission and MUST be ignored on reception.
保留：8位。传输时必须设置为零，接收时必须忽略。
Option-Length: The length of the AUTHENTICATION_TAG option for the common PCP message (in octets), including the 12-octet fixed-length header and the variable-length authentication data.
Option Length：公共PCP消息的AUTHENTICATION_标记选项的长度（以八位字节为单位），包括12个八位字节的固定长度标头和可变长度的身份验证数据。
Session ID: A 32-bit field used to identify the session to which the message belongs and identify the secret key used to create the message digest appended to the PCP message.
会话ID：一个32位字段，用于标识消息所属的会话，并标识用于创建附加到PCP消息的消息摘要的密钥。
Sequence Number: A 32-bit sequence number. In this option, a sequence number needs to be incremented on every new (non-retransmission) outgoing common PCP message in order to provide an ordering guarantee for common PCP messages.
序列号：32位序列号。在此选项中，每个新（非重传）传出的公共PCP消息都需要增加一个序列号，以便为公共PCP消息提供排序保证。
Key ID: The ID associated with the transport key used to generate authentication data. This field is filled with zeros if the MSK is directly used to secure the message.
密钥ID：与用于生成身份验证数据的传输密钥关联的ID。如果MSK直接用于保护消息，则此字段将用零填充。
Authentication Data: A variable-length field that carries the Message Authentication Code for the common PCP message. The generation of the digest varies according to the algorithms specified in different PCP SAs. This field MUST end on a 32-bit boundary, padded with zeros when necessary.
身份验证数据：一个可变长度字段，其中包含公共PCP消息的消息身份验证代码。摘要的生成因不同PCP SA中指定的算法而异。此字段必须在32位边界上结束，必要时用零填充。
This option is used to provide message authentication for PA messages. In contrast to the AUTHENTICATION_TAG option for common PCP messages, the Session ID field and the Sequence Number field are removed because such information is provided in the Opcode-specific information of the AUTHENTICATION Opcode.
此选项用于为PA消息提供消息身份验证。与普通PCP消息的AUTHENTICATION_TAG选项不同，会话ID字段和序列号字段被删除，因为此类信息在验证操作码的操作码特定信息中提供。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | Reserved | Option-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data (Variable) |
~ ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | Reserved | Option-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data (Variable) |
~ ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Code: 6.
选项代码：6。
Reserved: 8 bits. MUST be set to zero on transmission and MUST be ignored on reception.
保留：8位。传输时必须设置为零，接收时必须忽略。
Option-Length: The length of the PA_AUTHENTICATION option for the PCP Auth message (in octets), including the 4-octet fixed-length header and the variable-length authentication data.
Option Length：PCP Auth消息的PA_身份验证选项的长度（以八位字节为单位），包括4位八位字节的固定长度标头和可变长度身份验证数据。
Key ID: The ID associated with the transport key used to generate authentication data. This field is filled with zeros if the MSK is directly used to secure the message.
密钥ID：与用于生成身份验证数据的传输密钥关联的ID。如果MSK直接用于保护消息，则此字段将用零填充。
Authentication Data: A variable-length field that carries the Message Authentication Code for the PCP Auth message. The generation of the digest varies according to the algorithms
身份验证数据：携带PCP Auth消息的消息身份验证代码的可变长度字段。摘要的生成因算法而异
specified in different PCP SAs. This field MUST end on a 32-bit boundary, padded with null characters when necessary.
在不同的PCP SA中指定。此字段必须以32位边界结尾，必要时用空字符填充。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| EAP Message |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Code: 7.
选项代码：7。
Reserved: 8 bits. MUST be set to zero on transmission and MUST be ignored on reception.
保留：8位。传输时必须设置为零，接收时必须忽略。
Option-Length: Variable.
选项长度：可变。
EAP Message: The EAP message transferred. Note that this field MUST end on a 32-bit boundary, padded with zeros when necessary.
EAP消息：传输的EAP消息。请注意，此字段必须在32位边界上结束，必要时用零填充。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Code: 8.
选项代码：8。
Reserved: 8 bits. MUST be set to zero on transmission and MUST be ignored on reception.
保留：8位。传输时必须设置为零，接收时必须忽略。
Option-Length: 4 octets.
选项长度：4个八位字节。
PRF: The pseudorandom function that the sender supports to generate an MSK. This field contains a value indicating Internet Key Exchange Protocol version 2 (IKEv2) Transform Type 2 [RFC7296] [RFC4868]. A PCP implementation MUST support PRF_HMAC_SHA2_256 (transform ID = 5).
PRF：发送方支持生成MSK的伪随机函数。此字段包含一个值，该值指示Internet密钥交换协议版本2（IKEv2）转换类型2[RFC7296][RFC4868]。PCP实现必须支持PRF_HMAC_SHA2_256（转换ID=5）。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Code: 9.
选项代码：9。
Reserved: 8 bits. MUST be set to zero on transmission and MUST be ignored on reception.
保留：8位。传输时必须设置为零，接收时必须忽略。
Option-Length: 4 octets.
选项长度：4个八位字节。
MAC Algorithm ID: Indicates the MAC algorithm that the sender supports to generate authentication data. The MAC Algorithm ID field contains a value indicating IKEv2 Transform Type 3 [RFC7296] [RFC4868]. A PCP implementation MUST support AUTH_HMAC_SHA2_256_128 (transform ID = 12).
MAC算法ID：表示发送方支持生成认证数据的MAC算法。MAC算法ID字段包含一个值，该值指示IKEv2变换类型3[RFC7296][RFC4868]。PCP实现必须支持AUTH_HMAC_SHA2_256_128（转换ID=12）。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Code: 10.
选项代码：10。
Reserved: 8 bits. MUST be set to zero on transmission and MUST be ignored on reception.
保留：8位。传输时必须设置为零，接收时必须忽略。
Option-Length: 4 octets.
选项长度：4个八位字节。
Session Lifetime: An unsigned 32-bit integer, in seconds, ranging from 0 to 2^32-1 seconds. The lifetime of the PA session, which is decided by the authorization result.
会话生存期：一个无符号32位整数，以秒为单位，范围从0到2^32-1秒。PA会话的生存期，由授权结果决定。
This option is used in a PA-Acknowledgement message to indicate that a PA message with the contained sequence number has been received.
此选项用于PA确认消息中，以指示已接收到包含序列号的PA消息。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | Reserved | Option-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Received Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | Reserved | Option-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Received Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Code: 11.
选择代码：11。
Reserved: 8 bits. MUST be set to zero on transmission and MUST be ignored on reception.
保留：8位。传输时必须设置为零，接收时必须忽略。
Option-Length: 4 octets.
选项长度：4个八位字节。
Received Sequence Number: The sequence number of the last received PA message.
接收序列号：上次接收到的PA消息的序列号。
The ID_INDICATOR option is used by the PCP client to determine which credentials to provide to the PCP server.
PCP客户端使用ID_指示符选项来确定要向PCP服务器提供哪些凭据。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | Reserved | Option-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ID Indicator |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | Reserved | Option-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ID Indicator |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Code: 12.
选择代码：12。
Reserved: 8 bits. MUST be set to zero on transmission and MUST be ignored on reception.
保留：8位。传输时必须设置为零，接收时必须忽略。
Option-Length: Variable.
选项长度：可变。
ID Indicator: The identity of the authority that issued the EAP credentials to be used to authenticate the client. The field
ID指示符：颁发用于对客户端进行身份验证的EAP凭据的机构的标识。田野
MUST NOT be null terminated, and its length is indicated by the Option-Length field. In particular, when a client receives an ID_INDICATOR option, it MUST NOT rely on the presence of a null character in the wire format data to identify the end of the ID Indicator field.
不能以null结尾，其长度由选项长度字段指示。特别是，当客户端接收到ID_指示符选项时，它不能依赖wire格式数据中是否存在空字符来标识ID指示符字段的结尾。
The field MUST end on a 32-bit boundary, padded with zeros when necessary. The ID Indicator field is a UTF-8 encoded [RFC3629] Unicode string conforming to the UsernameCaseMapped profile of the PRECIS IdentifierClass [RFC7613]. The PCP client validates that the ID Indicator field conforms to the UsernameCaseMapped profile of the PRECIS IdentifierClass. The PCP client enforces the rules specified in Section 3.2.2 of [RFC7613] to map the ID Indicator field. The PCP client compares the resulting string with the ID indicators stored locally on the PCP client to pick the credentials for authentication. The two indicator strings are to be considered equivalent by the client if and only if they are an exact octet-for-octet match.
字段必须在32位边界上结束，必要时用零填充。ID指示符字段是一个UTF-8编码的[RFC3629]Unicode字符串，符合PRECIS IdentifierClass[RFC7613]的UsernameCaseMapped配置文件。PCP客户端验证ID指示符字段是否符合PRECIS IdentifierClass的UsernameCaseMapped配置文件。PCP客户端强制执行[RFC7613]第3.2.2节中指定的规则，以映射ID指示符字段。PCP客户端将生成的字符串与本地存储在PCP客户端上的ID指示符进行比较，以选择用于身份验证的凭据。当且仅当两个指示符字符串是八位字节匹配的精确八位字节时，客户端才认为它们是等效的。
After a successful EAP authentication process, every subsequent PCP message within the PA session MUST carry an authentication tag that contains the digest of the PCP message for data origin authentication and integrity protection.
在成功的EAP身份验证过程之后，PA会话中的每个后续PCP消息必须携带一个身份验证标签，该标签包含PCP消息摘要，用于数据源身份验证和完整性保护。
o Before generating a digest for a PA message, a device needs to first locate the PCP SA according to the session identifier and then get the transport key. Then, the device appends a PA_AUTHENTICATION_TAG option for PCP Auth at the end of the PCP Auth message. The length of the Authentication Data field is decided by the MAC algorithm adopted in the session. The device then fills the Key ID field with the key ID of the transport key and sets the Authentication Data field to zero. After this, the device generates a digest for the entire PCP message (including the PCP header and PA_AUTHENTICATION_TAG option) using the transport key and the associated MAC algorithm, and inserts the generated digest into the Authentication Data field.
o 在生成PA消息的摘要之前，设备需要首先根据会话标识符定位PCP SA，然后获取传输密钥。然后，设备在PCP Auth消息的末尾附加PCP Auth的PA_AUTHENTICATION_标记选项。身份验证数据字段的长度由会话中采用的MAC算法决定。然后，设备用传输密钥的密钥ID填充密钥ID字段，并将身份验证数据字段设置为零。在此之后，设备使用传输密钥和相关MAC算法为整个PCP消息（包括PCP报头和PA_认证标签选项）生成摘要，并将生成的摘要插入认证数据字段。
o Similar to generating a digest for a PA message, before generating a digest for a common PCP message, a device needs to first locate the PCP SA according to the session identifier and then get the transport key. Then, the device appends the AUTHENTICATION_TAG option at the end of the common PCP message. The length of the Authentication Data field is decided by the MAC algorithm adopted in the session. The device then uses the corresponding values
o 与为PA消息生成摘要类似，在为公共PCP消息生成摘要之前，设备需要首先根据会话标识符定位PCP SA，然后获取传输密钥。然后，设备在公共PCP消息的末尾附加身份验证标签选项。身份验证数据字段的长度由会话中采用的MAC算法决定。然后，设备使用相应的值
derived from the SA to fill the Session ID field, the Sequence Number field, and the Key ID field, and sets the Authentication Data field to zero. After this, the device generates a digest for the entire PCP message (including the PCP header and AUTHENTICATION_TAG option) using the transport key and the associated MAC algorithm, and inserts the generated digest into the Authentication Data field.
从SA派生以填充会话ID字段、序列号字段和密钥ID字段，并将身份验证数据字段设置为零。在此之后，设备使用传输密钥和相关MAC算法为整个PCP消息（包括PCP报头和认证标签选项）生成摘要，并将生成的摘要插入认证数据字段。
When a device receives a common PCP message with an AUTHENTICATION_TAG option for common PCP messages, the device needs to use the Session ID transported in the option to locate the proper SA and then find the associated transport key (using the key ID in the option) and the MAC algorithm. If no proper SA or transport key is found or the sequence number is invalid (see Section 6.5), the PCP device stops processing the PCP message and silently discards the message. After storing the value of the Authentication field of the AUTHENTICATION_TAG option, the device fills the Authentication field with zeros. Then, the device generates a digest for the message (including the PCP header and AUTHENTICATION_TAG option) with the transport key and the MAC algorithm. If the value of the newly generated digest is identical to the stored one, the device can ensure that the message has not been tampered with, and the validation succeeds. Otherwise, the PCP device stops processing the PCP message and silently discards the message.
当设备接收到带有公共PCP消息的身份验证标签选项的公共PCP消息时，设备需要使用该选项中传输的会话ID来定位适当的SA，然后查找相关的传输密钥（使用该选项中的密钥ID）和MAC算法。如果未找到正确的SA或传输密钥，或者序列号无效（参见第6.5节），PCP设备将停止处理PCP消息，并自动丢弃该消息。存储Authentication_标记选项的Authentication字段值后，设备将Authentication字段填充为零。然后，设备使用传输密钥和MAC算法生成消息摘要（包括PCP报头和认证标签选项）。如果新生成的摘要的值与存储的摘要的值相同，则设备可以确保消息未被篡改，并且验证成功。否则，PCP设备将停止处理PCP消息，并以静默方式丢弃该消息。
Similarly, when a device receives a PA message with a PA_AUTHENTICATION_TAG option for PCP authentication, the device needs to use the Session ID transported in the Opcode to locate the proper SA and then find the associated transport key (using the key ID in the option) and the MAC algorithm. If no proper SA or transport key is found or the sequence number is invalid (see Section 6.4), the PCP device stops processing the PCP message and silently discards the message. After storing the value of the Authentication field of the PA_AUTHENTICATION_TAG option, the device fills the Authentication field with zeros. Then, the device generates a digest for the message (including the PCP header and PA_AUTHENTICATION_TAG option) with the transport key and the MAC algorithm. If the value of the newly generated digest is identical to the stored one, the device can ensure that the message has not been tampered with, and the validation succeeds. Otherwise, the PCP device stops processing the PCP message and silently discards the message.
类似地，当设备接收到带有用于PCP认证的PA_AUTHENTICATION_标签选项的PA消息时，设备需要使用操作码中传输的会话ID来定位适当的SA，然后查找相关的传输密钥（使用选项中的密钥ID）和MAC算法。如果未找到正确的SA或传输密钥或序列号无效（参见第6.4节），PCP设备将停止处理PCP消息，并以静默方式丢弃该消息。存储PA_Authentication_标记选项的Authentication字段值后，设备将用零填充Authentication字段。然后，设备使用传输密钥和MAC算法生成消息摘要（包括PCP报头和PA_认证标签选项）。如果新生成的摘要的值与存储的摘要的值相同，则设备可以确保消息未被篡改，并且验证成功。否则，PCP设备将停止处理PCP消息，并以静默方式丢弃该消息。
Because EAP relies on the underlying protocols to provide reliable transmission, after sending a PA message, a PCP client/server MUST NOT send out any subsequent messages until it has received a PA message with a proper sequence number from the peer. If no such message is received, the PCP device will resend the last message according to retransmission policies. This specification uses the retransmission policies specified in Section 8.1.1 of the base PCP specification [RFC6887]. In base PCP, such retransmission policies are only applied by PCP clients. However, in this specification, such retransmission policies are also applied by the PCP servers. If the "maximum retransmission" duration (in seconds) has elapsed and no expected response is received, the device will terminate the session and discard the current SA.
由于EAP依赖底层协议提供可靠传输，因此在发送PA消息后，PCP客户机/服务器不得发送任何后续消息，直到它从对等方接收到具有正确序列号的PA消息。如果没有接收到这样的消息，则PCP设备将根据重传策略重新发送最后一条消息。本规范使用基本PCP规范[RFC6887]第8.1.1节中规定的重传策略。在基本PCP中，此类重传策略仅由PCP客户端应用。然而，在本规范中，此类重传策略也由PCP服务器应用。如果“最大重传”持续时间（以秒为单位）已过且未收到预期响应，则设备将终止会话并丢弃当前SA。
As discussed in Section 3.1.3, in order to avoid unnecessary retransmission, the device receiving a PA message MUST send a PA-Acknowledgement message to the sender of the PA message when it cannot send a PA response immediately. The PA-Acknowledgement message is used to indicate the receipt of the PA message. When the sender receives the PA-Acknowledgement message, it will stop the retransmission.
如第3.1.3节所述，为了避免不必要的重新传输，接收PA消息的设备必须在无法立即发送PA响应时向PA消息的发送方发送PA确认消息。PA确认消息用于指示收到PA消息。当发送方收到PA确认消息时，它将停止重传。
Note that the last PA messages transported within the phases of session initiation, session re-authentication, and session termination do not have to follow the above policies, since the devices sending out those messages do not expect any further PA messages.
注意，在会话启动、会话重新认证和会话终止阶段内传输的最后一个PA消息不必遵循上述策略，因为发送这些消息的设备不期望任何进一步的PA消息。
When a device receives a retransmitted last incoming PA message from its session partner, it MUST try to answer it by sending the last outgoing PA message again. However, if the duplicate message has the same sequence number but is not bitwise identical to the original message, then the device MUST discard it. In order to perform this function, the device may need to maintain the last incoming message and the associated outgoing messages. In this case, if no outgoing PA message has been generated for the received duplicate PA message yet, the device needs to send a PA-Acknowledgement message. The rate of replying to duplicate PA messages MUST be limited to provide robustness against denial-of-service (DoS) attacks. The details of rate limiting are outside the scope of this specification.
当设备从其会话伙伴接收到重新传输的最后一个传入PA消息时，它必须尝试通过再次发送最后一个传出PA消息来应答该消息。但是，如果重复消息具有相同的序列号，但与原始消息的位不相同，则设备必须丢弃它。为了执行此功能，设备可能需要维护最后一条传入消息和相关的传出消息。在这种情况下，如果尚未为接收到的重复PA消息生成传出PA消息，则设备需要发送PA确认消息。必须限制重复PA消息的回复速率，以提供对拒绝服务（DoS）攻击的鲁棒性。速率限制的细节不在本规范的范围内。
PCP uses UDP to transport signaling messages. As an unreliable transport protocol, UDP does not guarantee ordered packet delivery and does not provide any protection from packet loss. In order to ensure that the EAP messages are exchanged in a reliable way, every PCP message exchanged during EAP authentication must carry a monotonically increasing sequence number. During a PA session, a PCP device needs to maintain two sequence numbers for PA messages: one for incoming PA messages and one for outgoing PA messages. When generating an outgoing PA message, the device adds the associated outgoing sequence number to the message and increments the sequence number maintained in the SA by 1. When receiving a PA message from its session partner, the device will not accept it if the sequence number carried in the message does not match the incoming sequence number maintained in the device. After confirming that the received message is valid, the device increments the incoming sequence number maintained in the SA by 1.
PCP使用UDP传输信令消息。作为一种不可靠的传输协议，UDP不能保证有序的数据包传递，也不能提供任何防止数据包丢失的保护。为了确保EAP消息以可靠的方式交换，在EAP身份验证期间交换的每个PCP消息必须携带单调递增的序列号。在PA会话期间，PCP设备需要为PA消息维护两个序列号：一个用于传入PA消息，一个用于传出PA消息。生成传出PA消息时，设备将相关的传出序列号添加到消息中，并将SA中维护的序列号增加1。当从会话伙伴接收PA消息时，如果消息中包含的序列号与设备中维护的传入序列号不匹配，则设备将不接受该消息。在确认接收到的消息有效后，设备将SA中维护的传入序列号增加1。
The above rules are not applicable to PA-Acknowledgement messages (i.e., PA messages containing a RECEIVED_PAK option). A PA-Acknowledgement message does not transport any EAP message and only indicates that a PA message is received. Therefore, reliable transmission of PA-Acknowledgement messages is not required. For instance, after sending out a PA-Acknowledgement message, a device generates an EAP response. In this case, the device does not have to confirm whether the PA-Acknowledgement message has been received by its session partner or not. Therefore, when receiving or sending out a PA-Acknowledgement message, the device MUST NOT increase the corresponding sequence number stored in the SA. Otherwise, loss of a PA-Acknowledgement message will cause a mismatch in sequence numbers.
上述规则不适用于PA确认消息（即，包含已接收_-PAK选项的PA消息）。PA确认消息不传输任何EAP消息，仅指示接收到PA消息。因此，不需要可靠地传输PA确认消息。例如，在发送PA确认消息之后，设备生成EAP响应。在这种情况下，设备不必确认其会话伙伴是否已接收到PA确认消息。因此，当接收或发送PA确认消息时，设备不得增加存储在SA中的相应序列号。否则，PA确认消息的丢失将导致序列号不匹配。
Another exception is the message retransmission scenario. As discussed in Section 6.3, when a PCP device does not receive any response from its session partner, it needs to retransmit the last outgoing PA message, following the retransmission procedure specified in Section 8.1.1 of [RFC6887]. The original message and duplicate messages MUST be bitwise identical. When the device receives such a duplicate PA message from its session partner, it MUST send the last outgoing PA message again. In such cases, the maintained incoming and outgoing sequence numbers will not be affected by the message retransmission.
另一个例外是消息重传场景。如第6.3节所述，当PCP设备没有收到来自其会话伙伴的任何响应时，它需要按照[RFC6887]第8.1.1节中规定的重传程序重传最后一条传出的PA消息。原始消息和重复消息必须按位相同。当设备从其会话伙伴接收到这样一个重复的PA消息时，它必须再次发送最后一个传出的PA消息。在这种情况下，维护的传入和传出序列号将不受消息重传的影响。
When transporting common PCP messages within a PA session, a PCP device needs to maintain a sequence number for outgoing common PCP messages and a sequence number for incoming common PCP messages. When generating a new outgoing PCP message, the PCP device updates the Sequence Number field in the AUTHENTICATION_TAG option with the outgoing sequence number maintained in the SA and increments the outgoing sequence number by 1.
在PA会话中传输公共PCP消息时，PCP设备需要维护传出公共PCP消息的序列号和传入公共PCP消息的序列号。生成新的传出PCP消息时，PCP设备使用SA中维护的传出序列号更新身份验证标签选项中的序列号字段，并将传出序列号增加1。
When receiving a PCP message from its session partner, the PCP device will not accept it if the sequence number carried in the message is smaller than the incoming sequence number maintained in the device. This approach can protect the PCP device from replay attacks. After confirming that the received message is valid, the PCP device will update the incoming sequence number maintained in the PCP SA with the sequence number of the incoming message.
当从会话伙伴接收PCP消息时，如果消息中携带的序列号小于设备中维护的传入序列号，PCP设备将不接受该消息。这种方法可以保护PCP设备免受重播攻击。确认接收到的消息有效后，PCP设备将使用传入消息的序列号更新PCP SA中维护的传入序列号。
Note that the sequence number in the incoming message may not exactly match the incoming sequence number maintained locally. As discussed in the base PCP specification [RFC6887], if a PCP client is no longer interested in the PCP transaction and has not yet received a PCP response from the server, then it will stop retransmitting the PCP request. After that, the PCP client might generate new PCP requests for other purposes, using the current SA. In this case, the sequence number in the new request will be larger than the sequence number in the old request and so will be larger than the incoming sequence number maintained in the PCP server.
请注意，传入消息中的序列号可能与本地维护的传入序列号不完全匹配。如基本PCP规范[RFC6887]中所述，如果PCP客户端不再对PCP事务感兴趣，并且尚未从服务器收到PCP响应，则它将停止重新传输PCP请求。之后，PCP客户端可能会使用当前SA为其他目的生成新的PCP请求。在这种情况下，新请求中的序列号将大于旧请求中的序列号，因此将大于PCP服务器中维护的传入序列号。
Note that, as discussed in the base PCP specification [RFC6887], a PCP client needs to select a nonce in each MAP or PEER request, and the nonce is sent back in the response. However, it is possible for a client to use the same nonce in multiple MAP or PEER requests, and this may cause a potential risk of replay attacks. This attack is addressed by using the sequence number in the PCP response.
请注意，如基本PCP规范[RFC6887]中所述，PCP客户端需要在每个映射或对等请求中选择一个nonce，该nonce将在响应中发送回。但是，客户端可能在多个映射或对等请求中使用相同的nonce，这可能会导致重播攻击的潜在风险。此攻击通过使用PCP响应中的序列号来解决。
EAP methods are responsible for MTU handling, so no special facilities are required in PCP to deal with MTU issues. Specifically, EAP lower layers indicate to EAP methods and Authentication, Authorization, and Accounting (AAA) servers the MTU of the lower layer. EAP methods such as EAP-TLS [RFC5216], TEAP [RFC7170], and others that are likely to exceed reasonable MTUs provide support for fragmentation and reassembly. Others, such as EAP - Generalized Pre-Shared Key (EAP-GPSK) [RFC5433], assume that they will never send packets larger than the MTU and use small EAP packets.
EAP方法负责MTU处理，因此PCP中不需要特殊设施来处理MTU问题。具体而言，EAP较低层向EAP方法和身份验证、授权和计费（AAA）服务器指示较低层的MTU。EAP方法，如EAP-TLS[RFC5216]、TEAP[RFC7170]和其他可能超过合理MTU的方法，为碎片化和重新组装提供了支持。其他的，如EAP-通用预共享密钥（EAP-GPSK）[RFC5433]，则假定它们永远不会发送比MTU大的数据包，并且使用小的EAP数据包。
If an EAP message is too long to be transported within a single PA message, it will be divided into multiple sections and sent within different PA messages. Note that the receiver may not be able to know what to do in the next step until it has received all the sections and reconstructed the complete EAP message. In this case, in order to guarantee reliable message transmission, after receiving a PA message, the receiver replies with a PA-Acknowledgement message to notify the sender to send the next PA message.
如果EAP消息太长，无法在单个PA消息中传输，它将被分成多个部分，并在不同的PA消息中发送。注意，在接收到所有部分并重建完整的EAP消息之前，接收器可能无法知道下一步要做什么。在这种情况下，为了保证可靠的消息传输，在接收到PA消息之后，接收方回复PA确认消息以通知发送方发送下一个PA消息。
The following PCP Opcode has been allocated from the Standards Action range of the "PCP Opcodes" registry (which is maintained in <http://www.iana.org/assignments/pcp-parameters>):
以下PCP操作码已从“PCP操作码”注册表（在中维护）的标准操作范围中分配<http://www.iana.org/assignments/pcp-parameters>):
3 AUTHENTICATION.
3.认证。
The following PCP result codes have been allocated from the Standards Action range of the "PCP Result Codes" registry (which is maintained in <http://www.iana.org/assignments/pcp-parameters>):
以下PCP结果代码已从“PCP结果代码”注册表的标准操作范围中分配（该注册表保存在<http://www.iana.org/assignments/pcp-parameters>):
14 INITIATION: The client includes this PCP result code in its request to the server for authentication.
14初始化：客户端将此PCP结果代码包含在其对服务器的身份验证请求中。
15 AUTHENTICATION_REQUIRED: This error response is sent to the client if EAP authentication is required.
15需要身份验证：如果需要EAP身份验证，则将此错误响应发送到客户端。
16 AUTHENTICATION_FAILED: This error response is sent to the client if EAP authentication failed.
16身份验证失败：如果EAP身份验证失败，将向客户端发送此错误响应。
17 AUTHENTICATION_SUCCEEDED: This success response is sent to the client if EAP authentication succeeded.
17身份验证成功：如果EAP身份验证成功，则将此成功响应发送到客户端。
18 AUTHORIZATION_FAILED: This error response is sent to the client if EAP authentication succeeded but authorization failed.
18授权失败：如果EAP身份验证成功但授权失败，则向客户端发送此错误响应。
19 SESSION_TERMINATED: This PCP result code indicates to the partner that the PA session must be terminated.
19会话被终止：此PCP结果代码向合作伙伴指示必须终止PA会话。
20 UNKNOWN_SESSION_ID: This error response is sent from the PCP server if there is no known PA session associated with the Session ID sent in the PA request or common PCP request from the PCP client.
20 UNKNOWN_SESSION_ID：如果没有与PA请求或来自PCP客户端的公共PCP请求中发送的会话ID相关联的已知PA会话，则从PCP服务器发送此错误响应。
21 DOWNGRADE_ATTACK_DETECTED: This PCP result code indicates to the client that the server detected a downgrade attack.
21检测到降级攻击：此PCP结果代码向客户端指示服务器检测到降级攻击。
22 AUTHENTICATION_REQUEST: The server indicates to the client that the PA message contains an EAP request.
22身份验证请求：服务器向客户端指示PA消息包含EAP请求。
23 AUTHENTICATION_REPLY: The client indicates to the server that the PA message contains an EAP response.
23认证\u回复：客户端向服务器指示PA消息包含EAP响应。
The following PCP options have been allocated from the Standards Action range (the registry for PCP options is maintained in <http://www.iana.org/assignments/pcp-parameters>):
以下PCP选项已从标准操作范围中分配（PCP选项的注册表保存在<http://www.iana.org/assignments/pcp-parameters>):
Name: NONCE.
姓名：NONCE。
Value: 4.
价值：4。
Purpose: See Section 5.3.
目的：见第5.3节。
Valid for Opcodes: AUTHENTICATION.
对操作码有效：身份验证。
Length: 4 octets.
长度：4个八位组。
May appear in: Request and response.
可能出现在：请求和响应。
Maximum occurrences: 1.
最大发生次数：1。
Name: AUTHENTICATION_TAG.
名称：身份验证标签。
Value: 5.
数值：5。
Purpose: See Section 5.4.
目的：见第5.4节。
Valid for Opcodes: MAP, PEER, ANNOUNCE.
对操作码有效：映射、对等、宣布。
Length: variable.
长度：可变。
May appear in: Request and response.
可能出现在：请求和响应。
Maximum occurrences: 1.
最大发生次数：1。
Name: PA_AUTHENTICATION_TAG.
名称：PA_认证_标签。
Value: 6.
价值：6。
Purpose: See Section 5.5.
目的：见第5.5节。
Valid for Opcodes: AUTHENTICATION.
对操作码有效：身份验证。
Length: variable.
长度：可变。
May appear in: Request and response.
可能出现在：请求和响应。
Maximum occurrences: 1.
最大发生次数：1。
Name: EAP_PAYLOAD.
名称：EAP_有效载荷。
Value: 7.
数值：7。
Purpose: See Section 5.6.
目的：见第5.6节。
Valid for Opcodes: AUTHENTICATION.
对操作码有效：身份验证。
Length: variable.
长度：可变。
May appear in: Request and response.
可能出现在：请求和响应。
Maximum occurrences: 1.
最大发生次数：1。
Name: PRF.
姓名:PRF。
Value: 8.
数值：8。
Purpose: See Section 5.7.
目的：见第5.7节。
Valid for Opcodes: AUTHENTICATION.
对操作码有效：身份验证。
Length: 4 octets.
长度：4个八位组。
May appear in: Request and response.
可能出现在：请求和响应。
Maximum occurrences: as many as fit within maximum PCP message size.
最大出现次数：在最大PCP消息大小内尽可能多的出现次数。
Name: MAC_ALGORITHM.
名称：MAC_算法。
Value: 9.
数值：9。
Purpose: See Section 5.8.
目的：见第5.8节。
Valid for Opcodes: AUTHENTICATION.
对操作码有效：身份验证。
Length: 4 octets.
长度：4个八位组。
May appear in: Request and response.
可能出现在：请求和响应。
Maximum occurrences: as many as fit within maximum PCP message size.
最大出现次数：在最大PCP消息大小内尽可能多的出现次数。
Name: SESSION_LIFETIME.
名称：会话\u生命周期。
Value: 10.
数值：10。
Purpose: See Section 5.9.
目的：见第5.9节。
Valid for Opcodes: AUTHENTICATION
对操作码有效：身份验证
Length: 4 octets.
长度：4个八位组。
May appear in: Response.
可能出现在：响应。
Maximum occurrences: 1.
最大发生次数：1。
Name: RECEIVED_PAK.
姓名：吴白。
Value: 11.
数值：11。
Purpose: See Section 5.10.
目的：见第5.10节。
Valid for Opcodes: AUTHENTICATION.
对操作码有效：身份验证。
Length: 4 octets.
长度：4个八位组。
May appear in: Request and response.
可能出现在：请求和响应。
Maximum occurrences: 1.
最大发生次数：1。
Name: ID_INDICATOR.
名称：ID_指示器。
Value: 12.
数值：12。
Purpose: See Section 5.11.
目的：见第5.11节。
Valid for Opcodes: AUTHENTICATION.
对操作码有效：身份验证。
Length: variable.
长度：可变。
May appear in: Response.
可能出现在：响应。
Maximum occurrences: 1.
最大发生次数：1。
As described in this specification, after a successful EAP authentication process is performed between two PCP devices, an MSK will be exported. The MSK will be used to derive the transport keys to generate MAC digests for subsequent PCP message exchanges. However, before a transport key has been generated, the PA messages exchanged within a PA session have little cryptographic protection, and if there is no already-established security channel between two session partners, these messages are subject to man-in-the-middle attacks and DoS attacks. For instance, the initial PA-Server and PA-Client message exchange is vulnerable to spoofing attacks, as these messages are not authenticated and integrity protected. In addition, because the PRF and MAC algorithms are transported at this stage, an attacker may try to remove the PRF and MAC options containing strong algorithms from the initial PA-Server message and force the client to choose the weakest algorithms. Therefore, the server needs to guarantee that all the PRF and MAC algorithms for which it provides support are strong enough.
如本规范所述，在两个PCP设备之间成功执行EAP认证过程后，将导出MSK。MSK将用于导出传输密钥，以便为后续PCP消息交换生成MAC摘要。然而，在生成传输密钥之前，PA会话中交换的PA消息几乎没有密码保护，如果两个会话伙伴之间没有已建立的安全通道，则这些消息会受到中间人攻击和DoS攻击。例如，初始PA服务器和PA客户端消息交换容易受到欺骗攻击，因为这些消息未经身份验证且不受完整性保护。此外，由于PRF和MAC算法在此阶段传输，攻击者可能会尝试从初始PA服务器消息中删除包含强算法的PRF和MAC选项，并迫使客户端选择最弱的算法。因此，服务器需要保证其支持的所有PRF和MAC算法都足够强大。
In order to prevent very basic DoS attacks, a PCP device SHOULD generate state information as little as possible in the initial PA-Server and PA-Client message exchanges. The choice of EAP method is also very important. The selected EAP method must (1) be resilient to attacks that are possible in an insecure network environment, (2) provide user-identity confidentiality and protection against dictionary attacks, and (3) support session-key establishment.
为了防止非常基本的DoS攻击，PCP设备应在初始PA服务器和PA客户端消息交换中尽可能少地生成状态信息。EAP方法的选择也非常重要。所选EAP方法必须（1）能够抵御不安全网络环境中可能发生的攻击，（2）提供用户身份保密性和防止字典攻击的保护，以及（3）支持会话密钥建立。
When a PCP proxy [RFC7648] is located between a PCP server and PCP clients, the proxy may perform authentication with the PCP server before it processes requests from the clients. In addition,
当PCP代理[RFC7648]位于PCP服务器和PCP客户端之间时，该代理可以在处理来自客户端的请求之前执行与PCP服务器的身份验证。此外
re-authentication between the PCP proxy and PCP server will not interrupt the service that the proxy provides to the clients, since the proxy is still allowed to send common PCP messages to the PCP server during that period.
PCP代理和PCP服务器之间的重新身份验证不会中断代理向客户端提供的服务，因为在此期间仍允许代理向PCP服务器发送公共PCP消息。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，DOI 10.17487/RFC3629，2003年11月<http://www.rfc-editor.org/info/rfc3629>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, <http://www.rfc-editor.org/info/rfc3748>.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，编辑，“可扩展身份验证协议（EAP）”，RFC 3748，DOI 10.17487/RFC3748，2004年6月<http://www.rfc-editor.org/info/rfc3748>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007, <http://www.rfc-editor.org/info/rfc4868>.
[RFC4868]Kelly，S.和S.Frankel，“在IPsec中使用HMAC-SHA-256、HMAC-SHA-384和HMAC-SHA-512”，RFC 4868，DOI 10.17487/RFC4868，2007年5月<http://www.rfc-editor.org/info/rfc4868>.
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)", RFC 5281, DOI 10.17487/RFC5281, August 2008, <http://www.rfc-editor.org/info/rfc5281>.
[RFC5281]Funk，P.和S.Blake Wilson，“可扩展认证协议隧道传输层安全认证协议版本0（EAP-TTLSv0）”，RFC 5281，DOI 10.17487/RFC52812008年8月<http://www.rfc-editor.org/info/rfc5281>.
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 10.17487/RFC6887, April 2013, <http://www.rfc-editor.org/info/rfc6887>.
[RFC6887]Wing，D.，Ed.，Cheshire，S.，Boucadair，M.，Penno，R.，和P.Selkirk，“港口控制协议（PCP）”，RFC 6887，DOI 10.17487/RFC6887，2013年4月<http://www.rfc-editor.org/info/rfc6887>.
[RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, "Tunnel Extensible Authentication Protocol (TEAP) Version 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, <http://www.rfc-editor.org/info/rfc7170>.
[RFC7170]Zhou，H.，Cam Winget，N.，Salowey，J.，和S.Hanna，“隧道可扩展认证协议（TEAP）版本1”，RFC 7170，DOI 10.17487/RFC7170，2014年5月<http://www.rfc-editor.org/info/rfc7170>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7296]Kaufman，C.，Hoffman，P.，Nir，Y.，Eronen，P.，和T.Kivinen，“互联网密钥交换协议版本2（IKEv2）”，STD 79，RFC 7296，DOI 10.17487/RFC72962014年10月<http://www.rfc-editor.org/info/rfc7296>.
[RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords", RFC 7613, DOI 10.17487/RFC7613, August 2015, <http://www.rfc-editor.org/info/rfc7613>.
[RFC7613]Saint Andre，P.和A.Melnikov，“代表用户名和密码的国际化字符串的准备、实施和比较”，RFC 7613，DOI 10.17487/RFC7613，2015年8月<http://www.rfc-editor.org/info/rfc7613>.
[RFC7648] Perreault, S., Boucadair, M., Penno, R., Wing, D., and S. Cheshire, "Port Control Protocol (PCP) Proxy Function", RFC 7648, DOI 10.17487/RFC7648, September 2015, <http://www.rfc-editor.org/info/rfc7648>.
[RFC7648]Perreault，S.，Boucadair，M.，Penno，R.，Wing，D.，和S.Cheshire，“端口控制协议（PCP）代理功能”，RFC 7648，DOI 10.17487/RFC7648，2015年9月<http://www.rfc-editor.org/info/rfc7648>.
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, March 2008, <http://www.rfc-editor.org/info/rfc5216>.
[RFC5216]Simon，D.，Aboba，B.和R.Hurst，“EAP-TLS认证协议”，RFC 5216，DOI 10.17487/RFC5216，2008年3月<http://www.rfc-editor.org/info/rfc5216>.
[RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", RFC 5433, DOI 10.17487/RFC5433, February 2009, <http://www.rfc-editor.org/info/rfc5433>.
[RFC5433]Clancy，T.和H.Tschofenig，“可扩展认证协议-通用预共享密钥（EAP-GPSK）方法”，RFC 5433，DOI 10.17487/RFC5433，2009年2月<http://www.rfc-editor.org/info/rfc5433>.
[RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')", RFC 5448, DOI 10.17487/RFC5448, May 2009, <http://www.rfc-editor.org/info/rfc5448>.
[RFC5448]Arkko，J.，Lehtovirta，V.，和P.Eronen，“第三代身份验证和密钥协议（EAP-AKA'）的改进可扩展身份验证协议方法”，RFC 5448，DOI 10.17487/RFC5448，2009年5月<http://www.rfc-editor.org/info/rfc5448>.
Acknowledgements
致谢
Thanks to Dan Wing, Prashanth Patil, Dave Thaler, Peter Saint-Andre, Carlos Pignataro, Brian Haberman, Paul Kyzivat, Jouni Korhonen, Stephen Farrell, and Terry Manderson for their valuable comments.
感谢Dan Wing、Prashanth Patil、Dave Thaler、Peter Saint Andre、Carlos Pignataro、Brian Haberman、Paul Kyzivat、Jouni Korhonen、Stephen Farrell和Terry Manderson的宝贵评论。
Authors' Addresses
作者地址
Margaret Cullen Painless Security 356 Abbott Street North Andover, MA 01845 United States
Margaret Cullen无痛安全美国马萨诸塞州阿伯特北安多佛街356号01845
Phone: +1 781 405 7464
Email: margaret@painless-security.com
URI: http://www.painless-security.com
Phone: +1 781 405 7464
Email: margaret@painless-security.com
URI: http://www.painless-security.com
Sam Hartman Painless Security 356 Abbott Street North Andover, MA 01845 United States
Sam Hartman无痛安全美国马萨诸塞州阿伯特北安多佛街356号01845
Email: hartmans@painless-security.com
URI: http://www.painless-security.com
Email: hartmans@painless-security.com
URI: http://www.painless-security.com
Dacheng Zhang Beijing, China China
张大成，中国北京
Email: zhang_dacheng@hotmail.com
Email: zhang_dacheng@hotmail.com
Tirumaleswar Reddy Cisco Systems, Inc. Cessna Business Park, Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560103 India
Tirumaleswar Reddy Cisco Systems，Inc.印度卡纳塔克邦班加罗尔外环路瓦图尔霍布里萨贾普尔马拉塔利塞斯纳商业园560103
Email: tireddy@cisco.com
Email: tireddy@cisco.com