[要約] RFC 7652は、Port Control Protocol（PCP）の認証メカニズムに関するものであり、PCPメッセージの送信元の認証を提供する。目的は、PCPのセキュリティを向上させ、不正なアクセスや攻撃を防ぐことである。
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.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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サーバーがクライアントをExtensible Authentication Protocol（EAP）で認証できるようにするPCPセキュリティ拡張機能を定義します。 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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 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-Authentication（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セッションには、2つのセッションパートナー（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 Security Association（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-Authentication（PA）メッセージ：AUTHENTICATION Opcodeを含むPCPメッセージ。具体的には、PCPサーバーからPCPクライアントに送信されるPAメッセージはPA-Serverメッセージと呼ばれ、PCPクライアントからPCPサーバーに送信されるPAメッセージはPA-Clientメッセージと呼ばれます。したがって、PA-Serverメッセージは実際には[RFC6887]で指定されているPCP応答メッセージであり、PA-ClientメッセージはPCP要求メッセージです。このドキュメントでは、オプション-PCP認証用にセクション5.5で定義されたPA_AUTHENTICATION_TAGオプション-を指定して、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メッセージ：AUTHENTICATION Opcodeを含まないPCPメッセージ。このドキュメントでは、AUTHENTICATION_TAGオプションを指定して、一般的な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セッションの初めに、EAP認証プロセスを実行するために、PCPクライアントとPCPサーバーは一連のPAメッセージを交換する必要があります。各PAメッセージにはAUTHENTICATION Opcodeが含まれている必要があり、オプションで、さまざまな目的（認証メッセージの転送やセッション管理など）のためのオプションのセットを含めることができます。 AUTHENTICATION OpcodeのOpcode固有の情報は、セッションIDとシーケンス番号の2つのフィールドで構成されます。セッション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-Initiationメッセージ（結果コードINITIATIONを含むPA-Clientメッセージ）を送信します。セクション5.1は、PCP認証メカニズムの結果コードでPCP要求メッセージ形式を更新します。メッセージのOpcode固有の情報では、セッションIDおよびシーケンス番号フィールドがゼロに設定されています。 PA-Clientメッセージには、ランダムなナンスで構成される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 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-Initiationメッセージを受信した後、PCPサーバーがPCPクライアントとのPAセッションを開始することに同意すると、EAP要求を含むPA-Serverメッセージで応答し、このPA-Serverメッセージの結果コードフィールドはAUTHENTICATION_REQUESTに設定します。さらに、サーバーは、このセッションを明確に識別するために一意のセッション識別子を割り当て、PA-ServerメッセージのOpcode固有の情報のセッションIDフィールドにその識別子を挿入する必要があります。メッセージのシーケンス番号フィールドはゼロに設定されます。 PA-Serverメッセージには、ナンス値を返送するために、NONCEオプションが含まれている必要があります。その後、nonceはPCPクライアントによってこのメッセージの鮮度をチェックするために使用されます。この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) |
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サーバーはAUTHENTICATION_REQUIREDエラーコードで要求を拒否し、非送信請求PA-Serverメッセージで応答してPAセッションを開始できます。このPAサーバーメッセージの結果コードフィールドはAUTHENTICATION_REQUESTに設定されます。さらに、PCPサーバーはセッションにセッションIDを割り当て、PAサーバーメッセージ内で転送する必要があります。 PA-Serverメッセージのシーケンス番号フィールドはゼロに設定されます。 EAP認証が成功する前にPCPクライアントが共通の要求を再試行すると、PCPサーバーからAUTHENTICATION_REQUIREDエラーコードを受け取ります。このセッション中に交換される後続のPAメッセージでは、セッションIDを使用して、セッションパートナーがこのセッション内のメッセージとセッション内のメッセージを区別できるようにします。 PCPクライアントは、PCPサーバーからこの初期PA-Serverメッセージを受信すると、ローカルポリシーに従って、PA-Clientメッセージで応答するか、要求メッセージをサイレントに破棄できます。 PA-Clientメッセージでは、ランダムなnonceで構成されるNONCEオプションが追加される場合があります。その場合、次のPA-Serverメッセージで、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) |
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-Serverメッセージ内で転送され、EAP応答メッセージはPA-Clientメッセージ内で転送されます。 EAPは、信頼できる伝送を提供するために、基礎となるプロトコルに依存しています。再送信された配信または送信中に発生したパケットの損失は、検出して対処する必要があります。したがって、PA-Serverメッセージを送信した後、PCPサーバーは、PCPクライアントから適切なシーケンス番号のPA-Clientメッセージを受信するまで、同じPAセッションで新しいPA-Serverメッセージを送信しません。逆も同様です。 PCPクライアントがEAP要求を含むPAメッセージを受信し、何らかの理由でEAP応答をすぐに生成できない場合（たとえば、EAPメッセージを構築するための人間の入力を待つか、完全なメッセージを組み立てるために追加のPAメッセージを待つ）フラグメント化されたパケットからのEAPメッセージ）、PCPデバイスは、メッセージが受信されたことを示すために、PA確認応答メッセージ（RECEIVED_PAKオプションを指定したPAメッセージ）で応答する必要があります。このアプローチは、PAメッセージの不必要な再送信を回避できるだけでなく、EAP応答を生成する前にPCPデバイスがフラグメント化された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 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.
このアプローチでは、PCPクライアントとPCPサーバーは、認証でキー生成EAPメソッドを実行する必要があります。具体的には、PCP認証実装は拡張認証プロトコルトンネルトランスポート層セキュリティ（EAP-TTLS）[RFC5281]をサポートしなければならず（MUST）、トンネル拡張認証プロトコル（TEAP）[RFC7170]をサポートする必要があります。したがって、認証手順が成功すると、マスターセッションキー（MSK）が生成されます。 PCPクライアントとPCPサーバーがMSKを使用してトランスポートキーを生成する場合、トランスポートキーの導出のための疑似ランダム関数（PRF）とメッセージ認証コード（MAC）アルゴリズムについて合意し、その後のデータ発信元認証を提供する必要があります。 PCPメッセージ。これを行うには、PCPサーバーが最初のPA-Serverメッセージに一連のPRFオプションとMAC_ALGORITHMオプションを追加する必要があります。各PRFオプションには、PCPサーバーがサポートするPRFが含まれ、各MAC_ALGORITHMオプションには、PCPサーバーがサポートするMACアルゴリズムが含まれます。さらに、最初のPA-Serverメッセージでは、サーバーはID_INDICATORオプション（セクション5.11で定義）を付加して、クライアントに正しい資格情報を選択するように指示する場合があります（MAY）。オプションを受け取った後、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-Serverメッセージを送信して、EAP認証とPCP承認の結果を示します。 EAP認証が成功した場合、PAサーバーメッセージの結果コードはAUTHENTICATION_SUCCEEDEDです。この場合、PA-Serverメッセージを送信する前に、PCPサーバーはPCP SAをMSKおよびトランスポートキーで更新し、派生トランスポートキーを使用してメッセージのダイジェストを生成する必要があります。ダイジェストは、PCP AuthのPA_AUTHENTICATION_TAGオプション内で転送されます。認証データの生成の詳細については、セクション6.1を参照してください。さらに、PAサーバーメッセージには、PAセッションの存続期間（つまり、MSKの存続期間）を示すSESSION_LIFETIMEオプション（セクション5.9で定義）も含まれている必要があります。 PA-Serverメッセージを受信した後、PCPクライアントは応答としてPA-Clientメッセージを生成する必要があります。 PCPクライアントがPCPサーバーも認証する場合、PAクライアントメッセージの結果コードはAUTHENTICATION_SUCCEEDEDです。さらに、PCPクライアントはMSKとトランスポートキーでPCP SAを更新する必要があり、派生したトランスポートキーを使用してメッセージを保護します。それ以降、セッション内のすべてのPCPメッセージは、PCP SAで指定されたトランスポートキーとMACアルゴリズムで保護されます。クライアントからの最初の安全なPAクライアントメッセージには、PCPサーバーから受信したPRFおよびMAC_ALGORITHMオプションのセットが含まれている必要があります。 PCPサーバーは、アルゴリズムダウングレード攻撃を検出するために、クライアントによって伝達されたアルゴリズムのセットが最初に送信したアルゴリズムと一致するかどうかを判断します。サーバーがダウングレード攻撃を検出した場合は、結果コードDOWNGRADE_ATTACK_DETECTEDを含むPAサーバーメッセージを送信し、セッションを終了する必要があります。 PCPクライアントがAUTHENTICATION_TAGオプションなしでPAセッション内で共通のPCP要求を送信する場合、PCPサーバーはAUTHENTICATION_REQUIREDエラーコードを返すことで要求を拒否します。
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クライアント/サーバーがセッションパートナーを認証できない場合、デバイスは結果コードAUTHENTICATION_FAILEDを含むPAメッセージを送信します。 EAP認証は成功したが承認が失敗した場合、決定を行うデバイスは、結果コードAUTHORIZATION_FAILEDを含むPAメッセージを送信します。これらの2つのケースでは、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を失った場合、サーバーは[RFC6887]のセクション14.1.3で説明されているように、一方的なANNOUNCE応答をPCPクライアントに送信します。異常なエポックタイムのANNOUNCE応答を受信すると、PCPクライアントはサーバーが状態を失った可能性があると推定します。アナウンスは、偽の（攻撃）、正当な、またはクライアントに表示されません。これら3つのケースについて、以下で説明します。
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クライアントは、整合性が保護されたユニキャストANNOUNCE要求をPCPサーバーに送信して、PCPサーバーが実際に状態を失ったのか、攻撃者がANNOUNCE応答を送信したのかを確認します。
* 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セッションを失っていないと判断し、非請求のANNOUNCE応答が攻撃者によって送信されました。
* 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サーバーがANNOUNCE要求にUNKNOWN_SESSION_IDエラーコードで応答する場合、セクション3.1.1で説明されているように、PCPクライアントはPCPサーバーで完全なEAP認証を開始する必要があります。 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サーバーはUNKNOWN_SESSION_IDエラーコードで要求を拒否します。 PCPクライアントは、セクション3.1.1で説明されているように、PCPサーバーで完全なEAP認証を開始し、認証が成功した後で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 with an AUTHENTICATION_TAG option. The PCP server MUST update the PCP SA after successful EAP authentication.
PCPクライアントが再起動、電源障害、またはその他の理由によりPCP SAをリセットまたは失って、一般的なPCP要求を送信した場合、PCPサーバーはAUTHENTICATION_REQUIREDエラーコードで要求を拒否します。 PCPクライアントはPCPサーバーで認証する必要があり、EAP認証が成功した後、AUTHENTICATION_TAGオプションを使用して一般的なPCP要求を再試行します。 EAP認証が成功した後、PCPサーバーは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応答（結果コードがSESSION_TERMINATEDのPA応答）を送信することにより、セッションの終了を明示的に要求できます。終了を示すメッセージを受信すると、PCPクライアントは終了を示すPAメッセージで応答する必要があり、その後、関連付けられているPCP SAを削除する必要があります。パケット損失に対応するために、PCPサーバーは終了を示すPA応答を最大10回送信できます（送信間の時間の経過を反映するために、それぞれに適切なエポック時間値を使用）（1）最初の2つの間隔通知は少なくとも250ミリ秒で、（2）後続の通知間の各間隔は少なくとも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要求（結果コードがSESSION_TERMINATEDの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 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サーバーが再認証を開始する場合は、PCPクライアントにPA-Serverメッセージを送信します。メッセージの結果コードはRE-AUTHENTICATIONに設定されます。これは、メッセージが再認証プロセス用であることを示します。 PCPクライアントが再認証を開始する場合は、PA-Clientメッセージの結果コードをRE-AUTHENTICATIONに設定して、PAPクライアントメッセージをPCPサーバーに送信します。次に、セッションパートナーはPAメッセージを交換して、再認証のためにEAPメッセージを転送します。再認証手順の間、セッションパートナーは、現在のPCP SAで指定されたキーとMACアルゴリズムを使用して、PAメッセージの整合性を保護します。メッセージに関連付けられたシーケンス番号は、セクション6.4で指定されているように増加し続けます。 EAP要求を伝送するPA-Serverメッセージの結果コードはAUTHENTICATION_REQUIREDに設定され、EAP応答を伝送するPA-Clientメッセージは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-Serverメッセージの結果コードはAUTHENTICATION_SUCCEEDEDです。この場合、PA-Serverメッセージを送信する前に、PCPサーバーはSAを更新し、新しいキーを使用してPA-Serverメッセージと後続のPCPメッセージのダイジェストを生成する必要があります。さらに、PAサーバーメッセージには、PAセッションの新しい有効期間を示すSESSION_LIFETIMEオプションを追加する必要があります。 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-Serverメッセージの結果コードはAUTHENTICATION_FAILEDです。 EAP認証は成功したが承認が失敗した場合、最後のPA-Serverメッセージの結果コードはAUTHORIZATION_FAILEDです。後者の2つのケースでは、PAセッションは最後のPAメッセージ交換の直後に終了しなければなりません（MUST）。なんらかの理由で再認証が実行されず、セッションの有効期限が切れている場合、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メッセージを並行して交換することもできます。共通のPCPメッセージは、新しいSAが生成されるまで、現在のSAで保護する必要があります。再認証のために交換されるEAPメッセージのシーケンスは、PCPデバイスが再認証をトリガーするかどうかに関係なく変更されません。 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クライアントによって選択されたナンス。
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 ||ノンス||キー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」は、nullで終了していない文字列の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-Clientメッセージで転送されます。
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-Serverメッセージの形式は、[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を参照）を更新して、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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で指定された要求ヘッダーを使用します。Opcode固有のデータは、結果コード（例：INITIATION、AUTHENTICATION_FAILED）の転送に使用されます。図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 :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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-ClientメッセージのRequested LifetimeフィールドとPA-ServerメッセージのLifetimeフィールドは、送信時にゼロに設定され、受信時に無視されます。
The following diagram shows the format of the Opcode-specific information for the AUTHENTICATION Opcode.
次の図は、AUTHENTICATION Opcodeの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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Session ID: This field contains a 32-bit PA session identifier.
セッションID：このフィールドには、32ビットのPAセッションIDが含まれます。
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セッションのセッションIDはPCPサーバーによって決定されるため、PCPクライアントはPA-Initiationメッセージを送信するときに使用されるセッションIDを知りません。攻撃者がスプーフィングされたPA-Serverメッセージを送信して認証プロセスを妨害しないようにするために、PCPクライアントはPA-Initiationメッセージでナンスとして乱数を生成する必要があります。 PCPサーバーは、最初のPA-Serverメッセージ内にnonceを追加します。 PA-Serverメッセージに正しいナンスが含まれていない場合、メッセージはサイレントに破棄される必要があります。
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.
Option-Length：4オクテット。
Nonce: A random 32-bit number that is transported within a PA-Initiation message and the corresponding reply message from the PCP server.
ノンス：PA-Initiationメッセージと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) |
~ ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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メッセージには認証Opcodeがないため、一般的な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：12オクテットの固定長ヘッダーと可変長の認証データを含む、共通のPCPメッセージのAUTHENTICATION_TAGオプションの長さ（オクテット単位）。
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：メッセージが属するセッションを識別し、PCPメッセージに付加されるメッセージダイジェストを作成するために使用される秘密鍵を識別するために使用される32ビットのフィールド。
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フィールドとシーケンス番号フィールドは、AUTHENTICATIONオペコードのオペコード固有の情報で提供されるため、削除されます。
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：4オクテットの固定長ヘッダーと可変長の認証データを含む、PCP AuthメッセージのPA_AUTHENTICATIONオプションの長さ（オクテット単位）。
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 specified in different PCP SAs. This field MUST end on a 32-bit boundary, padded with null characters when necessary.
認証データ：PCP Authメッセージのメッセージ認証コードを運ぶ可変長フィールド。ダイジェストの生成は、さまざまなPCP SAで指定されたアルゴリズムによって異なります。このフィールドは32ビット境界で終了する必要があり、必要に応じてnull文字が埋め込まれます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Option-Length：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を生成するためにサポートする疑似ランダム関数。このフィールドには、インターネットキーエクスチェンジプロトコルバージョン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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Option-Length：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 Transform Type 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Option-Length：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.
セッション存続時間：0から2 ^ 32-1秒の範囲の秒単位の符号なし32ビット整数。 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Option-Length：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_INDICATORオプションを使用して、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 |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 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.
IDインジケーター：クライアントの認証に使用するEAP資格情報を発行した機関のID。フィールドはnullで終了してはならず（MUST NOT）、その長さはOption-Lengthフィールドで示されます。特に、クライアントがID_INDICATORオプションを受信する場合、IDインジケーターフィールドの終わりを識別するために、ワイヤー形式データ内のnull文字の存在に依存してはなりません（MUST NOT）。
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インジケーターフィールドは、PRECIS IdentifierClass [RFC7613]のUsernameCaseMappedプロファイルに準拠するUTF-8エンコード[RFC3629] Unicode文字列です。 PCPクライアントは、IDインジケーターフィールドがPRECIS IdentifierClassのUsernameCaseMappedプロファイルに準拠していることを検証します。 PCPクライアントは、[RFC7613]のセクション3.2.2で指定されたルールを適用して、IDインジケーターフィールドをマッピングします。 PCPクライアントは、結果の文字列をPCPクライアントにローカルに保存されているIDインジケーターと比較して、認証の資格情報を選択します。 2つのインジケーター文字列は、オクテットごとに完全に一致する場合にのみ、クライアントによって同等と見なされます。
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_TAGオプションを追加します。認証データフィールドの長さは、セッションで採用されているMACアルゴリズムによって決まります。次に、デバイスはキーIDフィールドにトランスポートキーのキーIDを入力し、認証データフィールドをゼロに設定します。この後、デバイスは、トランスポートキーと関連するMACアルゴリズムを使用して、PCPメッセージ全体（PCPヘッダーとPA_AUTHENTICATION_TAGオプションを含む）のダイジェストを生成し、生成されたダイジェストを認証データフィールドに挿入します。
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 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.
o PAメッセージのダイジェストを生成するのと同様に、デバイスは一般的なPCPメッセージのダイジェストを生成する前に、まずセッション識別子に従ってPCP SAを特定し、次にトランスポートキーを取得する必要があります。次に、デバイスは、共通PCPメッセージの最後にAUTHENTICATION_TAGオプションを追加します。認証データフィールドの長さは、セッションで採用されているMACアルゴリズムによって決まります。次に、デバイスはSAから派生した対応する値を使用して、セッションIDフィールド、シーケンス番号フィールド、およびキーIDフィールドに入力し、認証データフィールドをゼロに設定します。この後、デバイスは、トランスポートキーと関連するMACアルゴリズムを使用して、PCPメッセージ全体（PCPヘッダーとAUTHENTICATION_TAGオプションを含む）のダイジェストを生成し、生成されたダイジェストを認証データフィールドに挿入します。
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メッセージのAUTHENTICATION_TAGオプションを含む一般的なPCPメッセージを受信した場合、デバイスはオプションで転送されたセッションIDを使用して適切なSAを見つけ、関連するトランスポートキーを見つける必要があります（オプションのキーIDを使用）そしてMACアルゴリズム。適切なSAまたはトランスポートキーが見つからないか、シーケンス番号が無効である場合（セクション6.5を参照）、PCPデバイスはPCPメッセージの処理を停止し、メッセージを表示せずに破棄します。 AUTHENTICATION_TAGオプションの認証フィールドの値を保存した後、デバイスは認証フィールドをゼロで埋めます。次に、デバイスは、トランスポートキーとMACアルゴリズムを使用して、メッセージのダイジェスト（PCPヘッダーとAUTHENTICATION_TAGオプションを含む）を生成します。新しく生成されたダイジェストの値が保存されているダイジェストと同じ場合、デバイスはメッセージが改ざんされていないことを確認でき、検証が成功します。それ以外の場合、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_TAGオプションを使用してPAメッセージを受信すると、デバイスはOpcodeで転送されたセッションIDを使用して適切なSAを見つけ、関連するトランスポートキーを見つける必要があります（オプションのキーIDを使用）。そしてMACアルゴリズム。適切なSAまたはトランスポートキーが見つからないか、シーケンス番号が無効である場合（セクション6.4を参照）、PCPデバイスはPCPメッセージの処理を停止し、メッセージを通知せずに破棄します。 PA_AUTHENTICATION_TAGオプションの認証フィールドの値を格納した後、デバイスは認証フィールドをゼロで埋めます。次に、デバイスは、トランスポートキーとMACアルゴリズムを使用して、メッセージのダイジェスト（PCPヘッダーとPA_AUTHENTICATION_TAGオプションを含む）を生成します。新しく生成されたダイジェストの値が保存されているダイジェストと同じ場合、デバイスはメッセージが改ざんされていないことを確認でき、検証が成功します。それ以外の場合、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メッセージを受信するまで、後続のメッセージを送信してはなりません（MUST NOT）。そのようなメッセージが受信されない場合、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-Acknowledgementメッセージを送信する必要があります。 PA-Acknowledgementメッセージは、PAメッセージの受信を示すために使用されます。送信者がPA-Acknowledgementメッセージを受信すると、再送信を停止します。
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メッセージの2つのシーケンス番号を維持する必要があります。1つは着信PAメッセージ用、もう1つは発信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確認メッセージ（つまり、RECEIVED_PAKオプションを含むPAメッセージ）には適用されません。 PA-Acknowledgementメッセージは、EAPメッセージを転送せず、PAメッセージが受信されたことを示すだけです。したがって、PA-Acknowledgementメッセージを確実に送信する必要はありません。たとえば、PA-Acknowledgementメッセージを送信した後、デバイスはEAP応答を生成します。この場合、デバイスはPA-Acknowledgementメッセージがセッションパートナーによって受信されたかどうかを確認する必要はありません。したがって、PA-Acknowledgementメッセージを受信または送信する場合、デバイスは、SAに格納されている対応するシーケンス番号を増やしてはなりません（MUST NOT）。そうしないと、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.
もう1つの例外は、メッセージの再送信シナリオです。セクション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デバイスは、AUTHENTICATION_TAGオプションのシーケンス番号フィールドを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クライアントは各MAPまたはPEER要求でノンスを選択する必要があり、ノンスは応答で返送されることに注意してください。ただし、クライアントが複数のMAPまたはPEER要求で同じナンスを使用することは可能であり、これにより、リプレイ攻撃の潜在的なリスクが発生する可能性があります。この攻撃は、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処理を担当するため、MTUの問題に対処するためにPCPに特別な機能は必要ありません。具体的には、EAPの下位層は、EAPメソッドと認証、承認、およびアカウンティング（AAA）サーバーに下位層のMTUを示します。 EAP-TLS [RFC5216]、TEAP [RFC7170]、および妥当なMTUを超える可能性が高いその他のEAPメソッドは、断片化と再構成をサポートします。その他、EAP-Generalized Pre-Shared Key（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メッセージ内で転送できない場合、EAPメッセージは複数のセクションに分割され、異なるPAメッセージ内で送信されます。受信者は、すべてのセクションを受信して完全なEAPメッセージを再構築するまで、次のステップで何をすべきかを認識できない場合があることに注意してください。この場合、確実なメッセージ送信を保証するために、PAメッセージを受信した後、受信者はPA-Acknowledgementメッセージで応答し、送信者に次の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 Opcodeは、「PCP Opcodes」レジストリ（<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 INITIATION：クライアントは、認証のためのサーバーへの要求にこのPCP結果コードを含めます。
15 AUTHENTICATION_REQUIRED: This error response is sent to the client if EAP authentication is required.
15 AUTHENTICATION_REQUIRED：このエラー応答は、EAP認証が必要な場合にクライアントに送信されます。
16 AUTHENTICATION_FAILED: This error response is sent to the client if EAP authentication failed.
16 AUTHENTICATION_FAILED：このエラー応答は、EAP認証が失敗した場合にクライアントに送信されます。
17 AUTHENTICATION_SUCCEEDED: This success response is sent to the client if EAP authentication succeeded.
17 AUTHENTICATION_SUCCEEDED：EAP認証が成功した場合、この成功応答がクライアントに送信されます。
18 AUTHORIZATION_FAILED: This error response is sent to the client if EAP authentication succeeded but authorization failed.
18 AUTHORIZATION_FAILED：このエラー応答は、EAP認証は成功したが認証が失敗した場合にクライアントに送信されます。
19 SESSION_TERMINATED: This PCP result code indicates to the partner that the PA session must be terminated.
19 SESSION_TERMINATED：この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：このエラー応答は、PCPクライアントからのPA要求または共通PCP要求で送信されたセッションIDに関連付けられた既知のPAセッションがない場合に、PCPサーバーから送信されます。
21 DOWNGRADE_ATTACK_DETECTED: This PCP result code indicates to the client that the server detected a downgrade attack.
21 DOWNGRADE_ATTACK_DETECTED：このPCP結果コードは、サーバーがダウングレード攻撃を検出したことをクライアントに示します。
22 AUTHENTICATION_REQUEST: The server indicates to the client that the PA message contains an EAP request.
22 AUTHENTICATION_REQUEST：サーバーは、PAメッセージにEAP要求が含まれていることをクライアントに示します。
23 AUTHENTICATION_REPLY: The client indicates to the server that the PA message contains an EAP response.
23 AUTHENTICATION_REPLY：クライアントは、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.
オペコードに有効：AUTHENTICATION。
Length: 4 octets.
長さ：4オクテット。
May appear in: Request and response.
表示される可能性がある：リクエストとレスポンス。
Maximum occurrences: 1.
最大発生回数：1。
Name: AUTHENTICATION_TAG.
名前：AUTHENTICATION_TAG。
Value: 5.
値：5。
Purpose: See Section 5.4.
目的：5.4項を参照してください。
Valid for Opcodes: MAP, PEER, ANNOUNCE.
オペコードに有効：MAP、PEER、ANNOUNCE。
Length: variable.
長さ：可変。
May appear in: Request and response.
表示される可能性がある：リクエストとレスポンス。
Maximum occurrences: 1.
最大発生回数：1。
Name: PA_AUTHENTICATION_TAG.
名前：PA_AUTHENTICATION_TAG。
Value: 6.
値：6。
Purpose: See Section 5.5.
目的：セクション5.5を参照してください。
Valid for Opcodes: AUTHENTICATION.
オペコードに有効：AUTHENTICATION。
Length: variable.
長さ：可変。
May appear in: Request and response.
表示される可能性がある：リクエストとレスポンス。
Maximum occurrences: 1.
最大発生回数：1。
Name: EAP_PAYLOAD.
名前：EAP_PAYLOAD。
Value: 7.
値：7。
Purpose: See Section 5.6.
目的：5.6項を参照してください。
Valid for Opcodes: AUTHENTICATION.
オペコードに有効：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.
オペコードに有効：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_ALGORITHM。
Value: 9.
値：9。
Purpose: See Section 5.8.
目的：セクション5.8を参照してください。
Valid for Opcodes: AUTHENTICATION.
オペコードに有効：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.
名前：SESSION_LIFETIME。
Value: 10.
値：10。
Purpose: See Section 5.9.
目的：5.9項を参照してください。
Valid for Opcodes: AUTHENTICATION
オペコードに有効：AUTHENTICATION
Length: 4 octets.
長さ：4オクテット。
May appear in: Response.
表示される場合があります：応答。
Maximum occurrences: 1.
最大発生回数：1。
Name: RECEIVED_PAK.
名前：RECEIVED_PAK。
Value: 11.
値：11。
Purpose: See Section 5.10.
目的：セクション5.10を参照してください。
Valid for Opcodes: AUTHENTICATION.
オペコードに有効：AUTHENTICATION。
Length: 4 octets.
長さ：4オクテット。
May appear in: Request and response.
表示される可能性がある：リクエストとレスポンス。
Maximum occurrences: 1.
最大発生回数：1。
Name: ID_INDICATOR.
名前：ID_INDICATOR。
Value: 12.
値：12。
Purpose: See Section 5.11.
目的：セクション5.11を参照してください。
Valid for Opcodes: AUTHENTICATION.
オペコードに有効：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.
この仕様で説明されているように、2つのPCPデバイス間でEAP認証プロセスが正常に実行された後、MSKがエクスポートされます。 MSKは、後続のPCPメッセージ交換用のMACダイジェストを生成するためのトランスポートキーを導出するために使用されます。ただし、トランスポートキーが生成される前は、PAセッション内で交換されるPAメッセージは暗号で保護されておらず、2つのセッションパートナー間に確立済みのセキュリティチャネルがない場合、これらのメッセージは中間者の影響を受けます。攻撃とDoS攻撃。たとえば、最初のPAサーバーとPAクライアントのメッセージ交換は、認証されておらず、整合性が保護されていないため、スプーフィング攻撃に対して脆弱です。さらに、この段階ではPRFおよびMACアルゴリズムが転送されるため、攻撃者は強力なアルゴリズムを含むPRFおよびMACオプションを最初のPA-Serverメッセージから削除し、クライアントに最も弱いアルゴリズムを選択させる可能性があります。したがって、サーバーは、サポートを提供するすべての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-ServerとPA-Clientのメッセージ交換で可能な限り状態情報を生成するべきではありません（SHOULD）。 EAP方式の選択も非常に重要です。選択したEAP方式は、（1）安全でないネットワーク環境で発生する可能性のある攻撃への耐性があり、（2）ユーザーIDの機密性と辞書攻撃に対する保護を提供し、（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, 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プロキシ[RFC7648]がPCPサーバーとPCPクライアントの間にある場合、プロキシはクライアントからの要求を処理する前にPCPサーバーで認証を実行する場合があります。さらに、プロキシは引き続き共通の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、編、「Extensible Authentication Protocol（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]ケリー、S。、およびS.フランケル、「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、「Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0（EAP-TTLSv0）」、RFC 5281、DOI 10.17487 / RFC5281、2008年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、「Port Control Protocol（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、「Tunnel Extensible Authentication Protocol（TEAP）Version 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、「Internet Key Exchange Protocol Version 2（IKEv2）」、STD 79、RFC 7296、DOI 10.17487 / RFC7296 、2014年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、「Port Control Protocol（PCP）Proxy Function」、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]サイモン、D。、アボバ、B。、およびR.ハースト、「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、「Extensible Authentication Protocol-Generalized Pre-Shared Key（EAP-GPSK）Method」、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、「Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement（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 Abbott Street North Andover、MA 01845アメリカ合衆国
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 Painless Security 356 Abbott Street North Andover、MA 01845アメリカ合衆国
Email: hartmans@painless-security.com
URI: http://www.painless-security.com
Dacheng Zhang Beijing, China China
DA Cheng Zhang北京、中国中国
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. Cessna Business Park、Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore、Karnataka 560103 India
Email: tireddy@cisco.com