[要約] RFC 7171は、EAPトンネルメソッドのためのポスチャトランスポート（PT）プロトコルであり、セキュリティポリシーの適用やネットワークアクセス制御を支援するために設計されています。このRFCの目的は、EAPトンネルメソッドのポスチャ評価とポリシーの適用を効率的かつ安全に行うためのプロトコルを提供することです。
Internet Engineering Task Force (IETF) N. Cam-Winget
Request for Comments: 7171 Cisco Systems
Category: Standards Track P. Sangster
ISSN: 2070-1721 Symantec Corporation
May 2014
PT-EAP: Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP) Tunnel Methods
PT-EAP：拡張認証プロトコル（EAP）トンネル方式用のポスチャトランスポート（PT）プロトコル
Abstract
概要
This document specifies PT-EAP, a Posture Transport (PT) protocol based on the Extensible Authentication Protocol (EAP) and designed to be used only inside an EAP tunnel method protected by Transport Layer Security (TLS). The document also describes the intended applicability of PT-EAP.
このドキュメントでは、拡張認証プロトコル（EAP）に基づくポスチャトランスポート（PT）プロトコルであるPT-EAPを指定し、トランスポート層セキュリティ（TLS）で保護されたEAPトンネル方式内でのみ使用するように設計されています。このドキュメントでは、PT-EAPの意図された適用性についても説明しています。
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/rfc7171.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7171で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Prerequisites . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Message Diagram Conventions . . . . . . . . . . . . . . . 3
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.4. Conventions Used in This Document . . . . . . . . . . . . 4
1.5. Compatibility with Other Specifications . . . . . . . . . 4
2. Use of PT-EAP . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definition of PT-EAP . . . . . . . . . . . . . . . . . . . . 4
3.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 5
3.2. Version Negotiation . . . . . . . . . . . . . . . . . . . 6
3.3. PT-EAP Message Format . . . . . . . . . . . . . . . . . . 6
3.4. Preventing MITM Attacks with Channel Bindings . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
4.1. Trust Relationships . . . . . . . . . . . . . . . . . . . 9
4.1.1. Posture Transport Client . . . . . . . . . . . . . . 9
4.1.2. Posture Transport Server . . . . . . . . . . . . . . 10
4.2. Threats and Countermeasures . . . . . . . . . . . . . . . 10
4.2.1. Message Confidentiality . . . . . . . . . . . . . . . 11
4.2.2. Message Fabrication . . . . . . . . . . . . . . . . . 11
4.2.3. Message Modification . . . . . . . . . . . . . . . . 12
4.2.4. Denial of Service . . . . . . . . . . . . . . . . . . 12
4.2.5. NEA Asokan Attacks . . . . . . . . . . . . . . . . . 13
4.3. Candidate EAP Tunnel Method Protections . . . . . . . . . 13
4.4. Security Claims for PT-EAP as per RFC 3748 . . . . . . . 14
5. Requirements for EAP Tunnel Methods . . . . . . . . . . . . . 14
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7.1. Registry for PT-EAP Versions . . . . . . . . . . . . . . 17
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 18
This document specifies PT-EAP, a Posture Transport (PT) protocol protected by a TLS-protected EAP tunnel method. The PT protocol in the Network Endpoint Assessment (NEA) architecture is responsible for transporting Posture Broker (PB-TNC [RFC5793]) batches, often containing Posture Attributes (PA-TNC [RFC5792]), across the network between the NEA Client and NEA Server. The PT-EAP protocol must be protected by an outer TLS-based EAP tunnel method to ensure the exchanged messages are protected from a variety of threats from hostile intermediaries.
このドキュメントでは、TLSで保護されたEAPトンネル方式で保護されたポスチャトランスポート（PT）プロトコルであるPT-EAPについて説明します。ネットワークエンドポイントアセスメント（NEA）アーキテクチャのPTプロトコルは、ポスチャブローカー（PB-TNC [RFC5793]）バッチの転送を担当し、多くの場合、ポスチャ属性（PA-TNC [RFC5792]）を含み、NEAクライアントとNEAの間のネットワーク全体に渡ります。サーバ。 PT-EAPプロトコルは、外部のTLSベースのEAPトンネル方式で保護する必要があります。これにより、交換されるメッセージが敵意のある仲介者からのさまざまな脅威から確実に保護されます。
NEA protocols are intended to be used both for pre-admission assessment of endpoints joining the network and assessment of endpoints already present on the network. In order to support both usage models, two types of PT protocols are needed. One type of PT, PT-TLS [RFC6876], operates after the endpoint has an assigned IP address, layering on top of the IP protocol to carry a NEA exchange. The other type of PT operates before the endpoint gains any access to the IP network. This specification defines PT-EAP, the PT protocol used to assess endpoints before they gain access to the network.
NEAプロトコルは、ネットワークに参加するエンドポイントの承認前の評価と、ネットワーク上にすでに存在するエンドポイントの評価の両方に使用することを目的としています。両方の使用モデルをサポートするには、2種類のPTプロトコルが必要です。 PTの1つのタイプであるPT-TLS [RFC6876]は、エンドポイントにIPアドレスが割り当てられた後に動作し、IPプロトコルの上に重ねてNEA交換を実行します。もう1つのタイプのPTは、エンドポイントがIPネットワークにアクセスする前に動作します。この仕様は、ネットワークにアクセスする前にエンドポイントを評価するために使用されるPTプロトコルであるPT-EAPを定義しています。
PT-EAP is an inner EAP [RFC3748] method designed to be used inside a protected tunnel such as Tunnel EAP (TEAP) [RFC7170], EAP Flexible Authentication via Secure Tunneling (EAP-FAST) [RFC4851], or EAP Tunneled Transport Layer Security (EAP-TTLS) [RFC5281]. That is, an outer EAP method is typically a TLS-based EAP method that first establishes a protected tunnel by which other conversations, such as other EAP methods (e.g., "inner" EAP methods) can ensue under the tunnel protection.
PT-EAPは、トンネルEAP（TEAP）[RFC7170]、セキュアトンネリングによるEAPフレキシブル認証（EAP-FAST）[RFC4851]、またはEAPトンネルトランスポートレイヤーなどの保護されたトンネル内で使用するように設計された内部EAP [RFC3748]メソッドです。セキュリティ（EAP-TTLS）[RFC5281]。つまり、通常、外部EAP方式はTLSベースのEAP方式であり、最初に保護されたトンネルを確立します。これにより、他のEAP方式（「内部」EAP方式など）などの他の会話がトンネル保護の下で行われます。
This document does not define an architecture or reference model. Instead, it defines a protocol that works within the reference model described in the NEA Requirements specification [RFC5209]. The reader is assumed to be thoroughly familiar with that document.
このドキュメントでは、アーキテクチャや参照モデルを定義していません。代わりに、NEA要件仕様[RFC5209]で説明されている参照モデル内で機能するプロトコルを定義します。読者はそのドキュメントに完全に精通していることを前提としています。
This specification defines the syntax of PT-EAP messages using diagrams. Each diagram depicts the format and size of each field in bits. Implementations MUST send the bits in each diagram as they are shown, traversing the diagram from top to bottom and then from left to right within each line (which represents a 32-bit quantity). Multi-byte fields representing numeric values MUST be sent in network (big-endian) byte order.
この仕様は、ダイアグラムを使用してPT-EAPメッセージの構文を定義します。各図は、各フィールドのフォーマットとサイズをビット単位で示しています。実装は、図のように各図のビットを送信しなければなりません。各行内で図を上から下に、次に左から右に走査します（32ビットの数量を表します）。数値を表すマルチバイトフィールドは、ネットワーク（ビッグエンディアン）バイトオーダーで送信する必要があります。
Descriptions of bit field (e.g., flag) values are described referring to the position of the bit within the field. These bit positions are numbered from the most significant bit through the least significant bit so a one octet field with only bit 0 set has the value 0x80.
ビットフィールド（フラグなど）の値の説明は、フィールド内のビットの位置を参照して説明されています。これらのビット位置は、最上位ビットから最下位ビットまで番号が付けられているため、ビット0のみが設定された1オクテットフィールドの値は0x80です。
This document reuses many terms defined in the NEA Requirements document [RFC5209], such as "Posture Transport Client" and "Posture Transport Server". The reader is assumed to have read that document and understood it.
このドキュメントは、「Posture Transport Client」や「Posture Transport Server」など、NEA要件ドキュメント[RFC5209]で定義されている多くの用語を再利用しています。読者はそのドキュメントを読んで理解したと見なされます。
When defining the PT-EAP method, this specification does not use the terms "EAP peer" and "EAP authenticator". Instead, it uses the terms "NEA Client" and "NEA Server" since those are considered to be more familiar to NEA WG participants. However, these terms are equivalent for the purposes of this specification. The part of the NEA Client that terminates PT-EAP (generally in the Posture Transport Client) is the EAP peer for PT-EAP. The part of the NEA Server that terminates PT-EAP (generally in the Posture Transport Server) is the EAP authenticator for PT-EAP.
PT-EAPメソッドを定義する場合、この仕様では「EAPピア」および「EAPオーセンティケーター」という用語を使用しません。代わりに、「NEAクライアント」と「NEAサーバー」という用語を使用します。これらは、NEA WGの参加者にとってより身近なものと見なされているためです。ただし、これらの用語は、この仕様の目的では同等です。 PT-EAPを終了するNEAクライアントの部分（通常はポスチャトランスポートクライアント）は、PT-EAPのEAPピアです。 PT-EAPを終了するNEAサーバーの部分（通常はポスチャトランスポートサーバー内）は、PT-EAPのEAPオーセンティケーターです。
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]で説明されているように解釈されます。
One of the goals of the NEA effort is to deliver a single set of endpoint assessment standards, agreed upon by all parties. For this reason, the authors understand that the Trusted Computing Group (TCG) will be replacing its existing posture transport protocols with new versions that are equivalent to and interoperable with the NEA specifications.
NEAの取り組みの目標の1つは、すべての関係者が合意した単一セットのエンドポイント評価標準を提供することです。このため、著者らはTrusted Computing Group（TCG）が既存のポスチャトランスポートプロトコルをNEA仕様と同等で相互運用可能な新しいバージョンに置き換えることを理解しています。
PT-EAP is designed to encapsulate PB-TNC batches in a simple EAP method that can be carried within EAP tunnel methods. The EAP tunnel methods provide confidentiality and message integrity, so PT-EAP does not have to do so. Therefore, PT-EAP MUST be used inside a TLS-based EAP tunnel method that provides strong cryptographic authentication (possibly server only), message integrity, and confidentiality services.
PT-EAPは、PB-TNCバッチを、EAPトンネルメソッド内で実行できる単純なEAPメソッドにカプセル化するように設計されています。 EAPトンネル方式は機密性とメッセージの整合性を提供するため、PT-EAPはそうする必要はありません。したがって、PT-EAPは、強力な暗号化認証（おそらくサーバーのみ）、メッセージの整合性、および機密性サービスを提供するTLSベースのEAPトンネル方式の内部で使用する必要があります。
The PT-EAP protocol operates between a Posture Transport Client and a Posture Transport Server, allowing them to send PB-TNC batches to each other over an EAP tunnel method. When PT-EAP is used, the Posture Transport Client in the NEA reference model acts as an EAP peer (terminating the PT-EAP method on the endpoint), and the Posture Transport Server acts as an EAP authenticator (terminating the PT-EAP method on the NEA Server).
PT-EAPプロトコルは、ポスチャトランスポートクライアントとポスチャトランスポートサーバーの間で動作し、EAPトンネル方式を介してPB-TNCバッチを相互に送信できるようにします。 PT-EAPが使用される場合、NEA参照モデルのポスチャトランスポートクライアントはEAPピアとして機能し（エンドポイントでPT-EAPメソッドを終了）、ポスチャトランスポートサーバーはEAPオーセンティケーターとして機能します（PT-EAPメソッドを終了します） NEAサーバー）。
This section describes and defines the PT-EAP method. First, it provides a protocol overview. Second, it describes specific features like version negotiation. Third, it gives a detailed packet description. Finally, it describes how the tls-unique channel binding [RFC5929] may be used to bind PA-TNC exchanges to the EAP tunnel method, defeating man-in-the-middle (MITM) attacks such as the Asokan attack [Asokan].
このセクションでは、PT-EAPメソッドについて説明し、定義します。まず、プロトコルの概要を説明します。次に、バージョンネゴシエーションなどの特定の機能について説明します。 3番目に、詳細なパケットの説明を示します。最後に、tls固有のチャネルバインディング[RFC5929]を使用してPA-TNC交換をEAPトンネル方式にバインドし、Asokan攻撃[Asokan]などの中間者（MITM）攻撃を無効にする方法について説明します。
PT-EAP has two phases that follow each other in strict sequence: negotiation and data transport.
PT-EAPには、厳密な順序で互いに続く2つのフェーズ（ネゴシエーションとデータ転送）があります。
The PT-EAP method begins with the negotiation phase. The NEA Server starts this phase by sending a PT-EAP Start message: an EAP Request message of type PT-EAP with the S (Start) flag set. The NEA Server also sets the Version field as described in Section 3.2. This is the only message in the negotiation phase.
PT-EAP方式は、ネゴシエーションフェーズで始まります。 NEAサーバーは、PT-EAP開始メッセージ（S（開始）フラグが設定されたPT-EAPタイプのEAP要求メッセージ）を送信して、このフェーズを開始します。 NEAサーバーは、セクション3.2で説明されているように、バージョンフィールドも設定します。これは、交渉フェーズでの唯一のメッセージです。
The data transport phase is the only phase of PT-EAP where PB-TNC batches are allowed to be exchanged. This phase always starts with the NEA Client sending a PB-TNC batch to the NEA Server. The NEA Client and NEA Server then take turns sending a PB-TNC batch. The data transport phase always ends with an EAP Response message from the NEA Client to the NEA Server. The Data field of this message may have zero length if the NEA Server has just sent the last PB-TNC batch in the PB-TNC exchange.
データ転送フェーズは、PB-TNCバッチの交換が許可されるPT-EAPの唯一のフェーズです。このフェーズは常に、NEAクライアントがPB-TNCバッチをNEAサーバーに送信することから始まります。次に、NEAクライアントとNEAサーバーが交互にPB-TNCバッチを送信します。データ転送フェーズは常に、NEAクライアントからNEAサーバーへのEAP応答メッセージで終了します。 NEAサーバーがPB-TNC交換で最後のPB-TNCバッチを送信したばかりの場合、このメッセージのデータフィールドの長さがゼロになることがあります。
Note that the success of PT-EAP does not mean the overall authentication (using the outer EAP tunnel method) will succeed. Neither does the failure of PT-EAP mean that the overall authentication will fail. Success of the overall authentication depends on the policy configured by the administrator.
PT-EAPが成功しても、全体的な認証（外部EAPトンネル方式を使用）が成功するわけではないことに注意してください。また、PT-EAPの失敗は、認証全体が失敗することを意味しません。認証全体の成功は、管理者が構成したポリシーに依存します。
At the end of the PT-EAP method, the NEA Server will indicate success or failure to the EAP tunnel method. Some EAP tunnel methods may provide explicit confirmation of inner method success; others may not. This is out of scope for the PT-EAP method specification. Successful completion of PT-EAP does not imply successful completion of the overall authentication nor does PT-EAP failure imply overall failure. This depends on the administrative policy in place.
PT-EAP方式の最後に、NEAサーバーはEAPトンネル方式に成功または失敗を示します。一部のEAPトンネルメソッドでは、内部メソッドの成功を明示的に確認できます。他の人はそうしないかもしれません。これはPT-EAPメソッド仕様の範囲外です。 PT-EAPの正常な完了は、認証全体の正常な完了を意味するものではなく、PT-EAPの失敗は、全体的な失敗を意味するものでもありません。これは、実施されている管理ポリシーによって異なります。
The NEA Server and NEA Client may engage in an abnormal termination of the PT-EAP exchange at any time by simply stopping the exchange. This may also require terminating the EAP tunnel method, depending on the capabilities of the EAP tunnel method.
NEAサーバーとNEAクライアントは、単に交換を停止するだけで、いつでもPT-EAP交換の異常終了を引き起こす可能性があります。また、EAPトンネル方式の機能によっては、EAPトンネル方式を終了する必要があります。
PT-EAP version negotiation takes place in the first PT-EAP message sent by the NEA Server (the Start message) and the first PT-EAP message sent by the NEA Client (the response to the Start message). The NEA Server MUST set the Version field in the Start message to the maximum PT-EAP version that the NEA Server supports and is willing to accept.
PT-EAPバージョンのネゴシエーションは、NEAサーバーが送信した最初のPT-EAPメッセージ（開始メッセージ）と、NEAクライアントが送信した最初のPT-EAPメッセージ（開始メッセージへの応答）で行われます。 NEAサーバーは、開始メッセージのバージョンフィールドを、NEAサーバーがサポートし、受け入れる意思のある最大PT-EAPバージョンに設定する必要があります。
The NEA Client chooses the PT-EAP version to be used for the exchange and places this value in the Version field in its response to the Start message. The NEA Client SHOULD choose the value sent by the NEA Server if the NEA Client supports it. However, the NEA Client MAY set the Version field to a value less than the value sent by the NEA Server (for example, if the NEA Client only supports lesser PT-EAP versions). If the NEA Client only supports PT-EAP versions greater than the value sent by the NEA Server, the NEA Client MUST abnormally terminate the EAP negotiation.
NEAクライアントは、交換に使用するPT-EAPバージョンを選択し、この値を開始メッセージへの応答のバージョンフィールドに配置します。 NEAクライアントは、NEAクライアントがサポートしている場合、NEAサーバーから送信された値を選択する必要があります（SHOULD）。ただし、NEAクライアントは、バージョンフィールドをNEAサーバーから送信された値よりも小さい値に設定できます（たとえば、NEAクライアントがサポートするPT-EAPバージョンが小さい場合）。 NEAクライアントがNEAサーバーから送信された値より大きいPT-EAPバージョンのみをサポートする場合、NEAクライアントはEAPネゴシエーションを異常終了する必要があります。
If the version sent by the NEA Client is not acceptable to the NEA Server, the NEA Server MUST terminate the PT-EAP session immediately. Otherwise, the version sent by the NEA Client is the version of PT-EAP that MUST be used. Both the NEA Client and the NEA Server MUST set the Version field to the chosen version number in all subsequent PT-EAP messages in this exchange.
NEAクライアントから送信されたバージョンがNEAサーバーに受け入れられない場合、NEAサーバーはPT-EAPセッションをただちに終了する必要があります。それ以外の場合、NEAクライアントから送信されるバージョンは、使用する必要があるPT-EAPのバージョンです。 NEAクライアントとNEAサーバーはどちらも、この交換で後続のすべてのPT-EAPメッセージで、バージョンフィールドを選択したバージョン番号に設定する必要があります。
This specification defines version 1 of PT-EAP. Version 0 is reserved and MUST never be sent. New versions of PT-EAP (values 2-7) may be defined by Standards Action, as defined in [RFC5226].
この仕様は、PT-EAPのバージョン1を定義しています。バージョン0は予約されており、送信してはなりません。 PT-EAPの新しいバージョン（値2〜7）は、[RFC5226]で定義されているように、標準アクションによって定義される場合があります。
This section provides a detailed description of the fields in a PT-EAP message. For a description of the diagram conventions used here, see Section 1.2. Since PT-EAP is an EAP method, the first four fields (e.g., Code, Identifier, Length, and Type as shown in Figure 1) in each message are mandated by and defined in EAP. The other fields, e.g., Flags, Version, and Data are specific to PT-EAP.
このセクションでは、PT-EAPメッセージのフィールドについて詳しく説明します。ここで使用されている図の規則の説明については、セクション1.2を参照してください。 PT-EAPはEAP方式であるため、各メッセージの最初の4つのフィールド（図1に示すように、コード、識別子、長さ、およびタイプなど）はEAPによって義務付けられ、定義されています。その他のフィールド（フラグ、バージョン、データなど）は、PT-EAPに固有です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | Ver | Data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PT-EAP Message Format
図1：PT-EAPメッセージ形式
Code
コード
The Code field is one octet and identifies the type of the EAP message. The only values used for PT-EAP are:
Codeフィールドは1オクテットで、EAPメッセージのタイプを識別します。 PT-EAPに使用される値は次のとおりです。
1 Request
1リクエスト
2 Response
2応答
Identifier
識別する
The Identifier field is one octet and aids in matching Responses with Requests.
Identifierフィールドは1オクテットであり、応答と要求の照合に役立ちます。
Length
長さ
The Length field is two octets and indicates the length in octets of this PT-EAP message, starting from the Code field.
長さフィールドは2オクテットで、コードフィールドから始まるこのPT-EAPメッセージの長さをオクテットで示します。
Type
タイプ
54 (EAP Method Type [RFC3748] assignment for PT-EAP).
54（PT-EAPのEAPメソッドタイプ[RFC3748]割り当て）。
Flags
旗
+-+-+-+-+-+
|S R R R R|
+-+-+-+-+-+
S: Start
S：開始
Indicates the beginning of a PT-EAP exchange. This flag MUST be set only for the first message from the NEA Server. If the S flag is set, the EAP message MUST NOT contain Data.
PT-EAP交換の開始を示します。このフラグは、NEAサーバーからの最初のメッセージに対してのみ設定する必要があります。 Sフラグが設定されている場合、EAPメッセージにデータを含めることはできません。
R: Reserved
R：予約済み
This flag MUST be set to 0 and ignored upon receipt.
このフラグは0に設定する必要があり、受信時に無視されます。
Version
バージョン
This field is used for version negotiation, as described in Section 3.2.
セクション3.2で説明されているように、このフィールドはバージョンネゴシエーションに使用されます。
Data
データ
Variable length data. This field is processed by the PB layer and MUST include PB-TNC messages. For more information see PB-TNC [RFC5793].
可変長データ。このフィールドはPB層によって処理され、PB-TNCメッセージを含める必要があります。詳細については、PB-TNC [RFC5793]を参照してください。
The length of the Data field in a particular PT-EAP message may be determined by subtracting the length of the PT-EAP header fields from the value of the two-octet Length field.
特定のPT-EAPメッセージのデータフィールドの長さは、2オクテットの長さフィールドの値からPT-EAPヘッダーフィールドの長さを引くことで決定できます。
As described in the NEA Asokan Attack Analysis [RFC6813], a sophisticated MITM attack can be mounted against NEA systems. The attacker forwards PA-TNC messages from a healthy machine through an unhealthy one so that the unhealthy machine can gain network access. Because there are easier attacks on NEA systems, like having the unhealthy machine lie about its configuration, this attack is generally only mounted against machines with an External Measurement Agent (EMA). The EMA is a separate entity, difficult to compromise, that measures and attests to the configuration of the endpoint.
NEA麻生攻撃分析[RFC6813]で説明されているように、洗練されたMITM攻撃をNEAシステムに対して実装できます。攻撃者は、正常なマシンから正常でないマシンを介してPA-TNCメッセージを転送し、異常なマシンがネットワークにアクセスできるようにします。 NEAシステムへの攻撃は簡単です。たとえば、異常なマシンにその構成を偽らせるなどの理由により、この攻撃は通常、外部測定エージェント（EMA）を備えたマシンに対してのみ行われます。 EMAは、エンドポイントの構成を測定および証明する独立したエンティティであり、妥協が困難です。
To protect against NEA Asokan attacks, it is necessary for the Posture Broker on an EMA-equipped endpoint to pass the tls-unique channel binding [RFC5929] from PT-EAP's tunnel method to the EMA. This value can then be included in the EMA's attestation so that the Posture Validator responsible may then confirm that the value matches the tls-unique channel binding for its end of the tunnel. If the tls-unique values of the NEA Client and NEA Server match and this is confirmed by the EMA, then the posture sent by a trustworthy EMA (and thus the NEA Client) is from the same endpoint as the client side of the TLS connection (since the endpoint knows the tls-unique value) so no MITM is forwarding posture. If they differ, an attack has been detected, and the Posture Validator SHOULD fail its verification.
NEA Asokan攻撃から保護するには、EMAを装備したエンドポイントのポスチャブローカーがtls固有のチャネルバインディング[RFC5929]をPT-EAPのトンネルメソッドからEMAに渡す必要があります。次に、この値をEMAの証明書に含めることができます。これにより、責任のあるポスチャバリデーターは、値がトンネルの終わりのtls固有のチャネルバインディングと一致することを確認できます。 NEAクライアントとNEAサーバーのtls固有の値が一致し、これがEMAによって確認された場合、信頼できるEMA（したがってNEAクライアント）によって送信されるポスチャは、TLS接続のクライアント側と同じエンドポイントからのものです。 （エンドポイントはtls-unique値を知っているため）、MITMはポスチャを転送していません。それらが異なる場合、攻撃が検出されており、ポスチャバリデーターはその検証に失敗する必要があります（SHOULD）。
Note that tls-unique, as opposed to invoking a mutual cryptographic binding, is used as there is no keying material being generated by PT-EAP (the method is defined to facilitate the transport of posture data and is not an authentication method). However, the NEA Client may host an EMA that can be used as the means to cryptographically bind the tls-unique content that may be validated by the Posture Validator interfacing with the EAP Server. The binding of the tls-unique to the client authentication prevents the client's message from being used in another context. This prevents a poorly configured client from unintentionally compromising the NEA system. Strong mutual authentication of the NEA Server and Client is still REQUIRED to prevent the disclosure of possibly sensitive NEA Client information to an attacker.
相互暗号バインディングを呼び出すのではなく、tls-uniqueが使用されることに注意してください。これは、PT-EAPによって生成されるキー生成情報がないためです（この方法は、ポスチャデータの転送を容易にするために定義され、認証方法ではありません）。ただし、NEAクライアントは、EAPサーバーと接続するポスチャバリデーターによって検証されるtls固有のコンテンツを暗号でバインドする手段として使用できるEMAをホストする場合があります。 tls-uniqueをクライアント認証にバインドすると、クライアントのメッセージが別のコンテキストで使用されなくなります。これにより、不適切に構成されたクライアントが意図せずにNEAシステムを危険にさらすことが防止されます。 NEAサーバーとクライアントの強力な相互認証は、機密性の高いNEAクライアント情報が攻撃者に開示されるのを防ぐために依然として必要です。
This section discusses the major threats and countermeasures provided by PT-EAP. As discussed throughout the document, the PT-EAP method is designed to run inside an EAP tunnel method that is capable of protecting the PT-EAP protocol from many threats. Since the EAP tunnel method will be specified separately, this section describes the considerations on the EAP tunnel method but does not evaluate its ability to meet those requirements. The security considerations and requirements for NEA can be found in [RFC5209].
このセクションでは、PT-EAPによって提供される主要な脅威と対策について説明します。このドキュメント全体で説明されているように、PT-EAPメソッドは、多くの脅威からPT-EAPプロトコルを保護できるEAPトンネルメソッド内で実行されるように設計されています。 EAPトンネル方式は個別に指定されるため、このセクションではEAPトンネル方式に関する考慮事項について説明しますが、それらの要件を満たす能力を評価しません。 NEAのセキュリティに関する考慮事項と要件は、[RFC5209]にあります。
In order to understand where security countermeasures are necessary, this section starts with a discussion of where the NEA architecture envisions some trust relationships between the processing elements of the PT-EAP protocol. The following sub-sections discuss the trust properties associated with each portion of the NEA reference model directly involved with the processing of the PT-EAP protocol flowing inside an EAP tunnel.
セキュリティ対策が必要な場所を理解するために、このセクションではまず、NEAアーキテクチャがPT-EAPプロトコルの処理要素間の信頼関係を想定する場所について説明します。次のサブセクションでは、EAPトンネル内を流れるPT-EAPプロトコルの処理に直接関係するNEA参照モデルの各部分に関連付けられている信頼プロパティについて説明します。
The Posture Transport Client is trusted by the Posture Broker Client to:
ポスチャトランスポートクライアントは、ポスチャブローカクライアントから次のことを信頼されています。
o Not disclose to unauthorized parties, fabricate, or alter the contents of the PB-TNC batches received from the network.
o ネットワークから受信したPB-TNCバッチの内容を、許可されていない当事者に開示したり、作成したり、変更したりしないでください。
o Not observe, fabricate, or alter the PB-TNC batches passed down from the Posture Broker Client for transmission on the network.
o ネットワークでの送信のためにPosture Broker Clientから渡されたPB-TNCバッチを観察、製造、または変更しないでください。
o Transmit on the network any PB-TNC batches passed down from the Posture Broker Client.
o Posture Broker Clientから渡されたPB-TNCバッチをネットワークで送信します。
o Provide configured security protections (e.g., authentication, integrity, and confidentiality) for the Posture Broker Client's PB-TNC batches sent on the network.
o ネットワーク上で送信されるポスチャブローカークライアントのPB-TNCバッチに構成済みのセキュリティ保護（認証、整合性、機密性など）を提供します。
o Expose the authenticated identity of the Posture Transport Server to the Posture Broker Client.
o ポスチャトランスポートサーバーの認証済みIDをポスチャブローカークライアントに公開します。
o Verify the security protections placed upon messages received from the network to ensure the messages are authentic and protected from attacks on the network.
o ネットワークから受信したメッセージに適用されているセキュリティ保護を検証して、メッセージが信頼でき、ネットワークへの攻撃から保護されていることを確認します。
o Deliver to the Posture Broker Client the PB-TNC batches received from the network so long as they are properly security protected.
o 適切にセキュリティ保護されている限り、ネットワークから受信したPB-TNCバッチをポスチャブローカークライアントに配信します。
o Provide a secure, reliable, "in-order delivery", full-duplex transport for the Posture Broker Client's messages.
o ポスチャブローカークライアントのメッセージに対して、安全で信頼性の高い、「順序どおりの配信」、全二重トランスポートを提供します。
Since the Posture Transport Server can not validate the trustworthiness of the Posture Transport Client, the Posture Transport Server should protect itself appropriately.
ポスチャトランスポートサーバーはポスチャトランスポートクライアントの信頼性を検証できないため、ポスチャトランスポートサーバーは適切に自身を保護する必要があります。
The Posture Transport Server is trusted by the Posture Broker Server to:
ポスチャトランスポートサーバーは、ポスチャーブローカーサーバーから次のことを信頼されます。
o Not observe, fabricate, or alter the contents of the PB-TNC batches received from the network.
o ネットワークから受信したPB-TNCバッチの内容を観察、加工、または変更しないでください。
o Not observe, fabricate, or alter the PB-TNC batches passed down from the Posture Broker Server for transmission on the network.
o ネットワークでの送信用にPosture Broker Serverから渡されたPB-TNCバッチを観察、製造、または変更しないでください。
o Transmit on the network any PB-TNC batches passed down from the Posture Broker Server.
o Posture Broker Serverから渡されたPB-TNCバッチをネットワークで送信します。
o Ensure PB-TNC batches received from the network are properly protected from a security perspective.
o ネットワークから受信したPB-TNCバッチがセキュリティの観点から適切に保護されていることを確認してください。
o Provide configured security protections (e.g., authentication, integrity, and confidentiality) for the Posture Broker Server's messages sent on the network.
o ネットワーク上で送信されるPosture Broker Serverのメッセージに、構成されたセキュリティ保護（認証、整合性、機密性など）を提供します。
o Expose the authenticated identity of the Posture Transport Client to the Posture Broker Server.
o Posture Transport Clientの認証済みIDをPosture Broker Serverに公開します。
o Verify the security protections placed upon messages received from the network to ensure the messages are authentic and protected from attacks on the network.
o ネットワークから受信したメッセージに適用されているセキュリティ保護を検証して、メッセージが信頼でき、ネットワークへの攻撃から保護されていることを確認します。
Since the Posture Transport Client can not validate the trustworthiness of the Posture Transport Server, the Posture Transport Client should protect itself appropriately.
ポスチャトランスポートクライアントはポスチャトランスポートサーバーの信頼性を検証できないため、ポスチャトランスポートクライアントは自身を適切に保護する必要があります。
Beyond the trusted relationships assumed in Section 4.1, the PT-EAP EAP method faces a number of potential security attacks that could require security countermeasures.
セクション4.1で想定されている信頼関係を超えて、PT-EAP EAPメソッドは、セキュリティ対策を必要とする可能性のある潜在的なセキュリティ攻撃に直面しています。
Generally, the PT protocol is responsible for providing strong security protections for all of the NEA protocols so any threats to PT's ability to protect NEA protocol messages could be very damaging to deployments. For the PT-EAP method, most of the cryptographic security is provided by the outer EAP tunnel method, and PT-EAP is encapsulated within the protected tunnel. Therefore, this section highlights the cryptographic requirements that need to be met by the EAP tunnel method carrying PT-EAP in order to meet the NEA PT requirements.
一般に、PTプロトコルは、すべてのNEAプロトコルに強力なセキュリティ保護を提供する責任があるため、PTのNEAプロトコルメッセージを保護する能力に対する脅威は、展開に非常に損害を与える可能性があります。 PT-EAP方式の場合、暗号化セキュリティのほとんどは外部EAPトンネル方式によって提供され、PT-EAPは保護されたトンネル内にカプセル化されます。したがって、このセクションでは、NEA PT要件を満たすためにPT-EAPを伝送するEAPトンネル方式で満たす必要がある暗号要件を強調表示します。
Once the message is delivered to the Posture Broker Client or Posture Broker Server, the Posture Brokers are trusted to properly and safely process the messages.
メッセージがPosture Broker ClientまたはPosture Broker Serverに配信されると、Posture Brokerはメッセージを適切かつ安全に処理することが信頼されます。
When PT-EAP messages are sent over unprotected network links or span local software stacks that are not trusted, the contents of the messages may be subject to information theft by an intermediary party. This theft could result in information being recorded for future use or analysis by an adversary. Messages observed by eavesdroppers could contain information that exposes potential weaknesses in the security of the endpoint or system fingerprinting information easing the ability of the attacker to employ attacks more likely to be successful against the endpoint. The eavesdropper might also learn information about the endpoint or network policies that either singularly or collectively is considered sensitive information. For example, if PT-EAP is carried by an EAP tunnel method that does not provide confidentiality protection, an adversary could observe the PA-TNC attributes included in the PB-TNC batch and determine that the endpoint is lacking patches or that particular sub-networks have more lenient policies.
保護されていないネットワークリンクを介して、または信頼されていないローカルソフトウェアスタックにまたがってPT-EAPメッセージが送信される場合、メッセージの内容は、中間者による情報の盗難の対象となる可能性があります。この盗難により、将来の使用または敵による分析のために情報が記録される可能性があります。盗聴者によって観察されるメッセージには、エンドポイントのセキュリティの潜在的な弱点を明らかにする情報や、エンドポイントに対して攻撃を成功させる可能性が高い攻撃を実行する攻撃者の能力を容易にするシステムのフィンガープリント情報が含まれる可能性があります。盗聴者は、単独または集合的に機密情報と見なされるエンドポイントまたはネットワークポリシーに関する情報を知ることもあります。たとえば、機密保護を提供しないEAPトンネル方式でPT-EAPが実行されている場合、攻撃者はPB-TNCバッチに含まれるPA-TNC属性を観察し、エンドポイントにパッチまたはその特定のサブネットワークにはより寛大なポリシーがあります。
In order to protect against NEA assessment message theft, the EAP tunnel method carrying PT-EAP must provide strong cryptographic authentication, integrity, and confidentiality protection. The use of bidirectional authentication in the EAP tunnel method carrying PT-EAP ensures that only properly authenticated and authorized parties may be involved in an assessment message exchange. When PT-EAP is carried within a cryptographically protected EAP tunnel method like EAP-FAST or EAP-TTLS, all of the contents of PB-TNC and PA-TNC protocol messages are hidden from potential theft by intermediaries lurking on the network.
NEA評価メッセージの盗難から保護するために、PT-EAPを伝送するEAPトンネル方式は、強力な暗号化認証、整合性、および機密保護を提供する必要があります。 PT-EAPを伝送するEAPトンネル方式で双方向認証を使用すると、適切に認証および許可された関係者のみが評価メッセージの交換に関与できるようになります。 PT-EAPがEAP-FASTやEAP-TTLSなどの暗号で保護されたEAPトンネル方式内で伝送される場合、PB-TNCおよびPA-TNCプロトコルメッセージのすべてのコンテンツは、ネットワークに潜む仲介者によって潜在的な盗難から隠されます。
Attackers on the network or present within the NEA system could introduce fabricated PT-EAP messages intending to trick or create a denial of service against aspects of an assessment. For example, an adversary could attempt to insert a PT-EAP message to tell a NEA Server that the endpoint is totally infected. This could cause the device to be blocked from accessing a critical resource, which would be a denial of service.
ネットワーク上の攻撃者またはNEAシステム内に存在する攻撃者は、評価の側面に対してサービス拒否をだましまたは作成することを目的とした、偽造されたPT-EAPメッセージを導入する可能性があります。たとえば、攻撃者はPT-EAPメッセージを挿入して、NEAサーバーにエンドポイントが完全に感染していることを通知する可能性があります。これにより、デバイスが重要なリソースへのアクセスをブロックされる可能性があり、これはサービス拒否となります。
The EAP tunnel method carrying a PT-EAP method needs to provide strong security protections for the complete message exchange over the network. These security protections prevent an intermediary from being able to insert fake messages into the assessment. See Section 5 for more details on the EAP tunnel requirements.
PT-EAP方式を伝送するEAPトンネル方式は、ネットワーク上の完全なメッセージ交換のために強力なセキュリティ保護を提供する必要があります。これらのセキュリティ保護により、中間者が偽のメッセージを評価に挿入することができなくなります。 EAPトンネルの要件の詳細については、セクション5を参照してください。
This attack could allow an active attacker capable of intercepting a message to modify a PT-EAP message or transported PA-TNC attribute to a desired value to ease the compromise of an endpoint. Without the ability for message recipients to detect whether a received message contains the same content as what was originally sent, active attackers can stealthily modify the attribute exchange.
この攻撃では、メッセージを傍受できるアクティブな攻撃者がPT-EAPメッセージまたはトランスポートされたPA-TNC属性を目的の値に変更して、エンドポイントの侵害を容易にする可能性があります。メッセージの受信者が、受信したメッセージに最初に送信されたものと同じコンテンツが含まれているかどうかを検出する機能がない場合、アクティブな攻撃者は属性交換を密かに変更できます。
PT-EAP leverages the EAP tunnel method (e.g., TEAP, EAP-FAST, or EAP-TTLS) to provide strong authentication and integrity protections as a countermeasure to this threat. The bidirectional authentication prevents the attacker from acting as an active MITM to the protocol that could be used to modify the message exchange. The strong integrity protections offered by the TLS-based EAP tunnel method allow the PT-EAP message recipients to detect message alterations by other types of network-based adversaries. Because PT-EAP does not itself provide explicit integrity protection for the PT-EAP payload, an EAP tunnel method that offers strong integrity protection is needed to mitigate this threat.
PT-EAPは、EAPトンネル方式（TEAP、EAP-FAST、EAP-TTLSなど）を利用して、この脅威への対策として強力な認証と整合性保護を提供します。双方向認証により、攻撃者がメッセージ交換の変更に使用される可能性のあるプロトコルに対してアクティブなMITMとして機能することを防ぎます。 TLSベースのEAPトンネル方式によって提供される強力な整合性保護により、PT-EAPメッセージの受信者は、他のタイプのネットワークベースの攻撃者によるメッセージの変更を検出できます。 PT-EAP自体はPT-EAPペイロードの明示的な整合性保護を提供しないため、この脅威を軽減するには、強力な整合性保護を提供するEAPトンネル方式が必要です。
A variety of types of denial-of-service attacks are possible against PT-EAP if the message exchange is left unprotected while traveling over the network. The Posture Transport Client and Posture Transport Server are trusted not to participate in the denial of service of the assessment session, leaving the threats to come from the network.
ネットワーク上を移動中のメッセージ交換が保護されていない場合、PT-EAPに対してさまざまなタイプのサービス拒否攻撃が可能です。ポスチャトランスポートクライアントとポスチャトランスポートサーバーは、評価セッションのサービス拒否に参加しないことが信頼されているため、脅威はネットワークから発信されます。
The PT-EAP method primarily relies on the outer EAP tunnel method to provide strong authentication (at least of one party), and deployers are expected to leverage other EAP methods to authenticate the other party (typically the client) within the protected tunnel. The use of a protected bidirectional authentication will prevent unauthorized parties from participating in a PT-EAP exchange.
PT-EAP方式は、主に外部EAPトンネル方式に依存して強力な認証を提供し（少なくとも一方のパーティ）、デプロイヤは他のEAP方式を利用して、保護されたトンネル内で他方のパーティ（通常はクライアント）を認証することが期待されます。保護された双方向認証を使用すると、許可されていない当事者がPT-EAP交換に参加するのを防ぐことができます。
After the cryptographic authentication by the EAP tunnel method, the session can be protected cryptographically to provide confidentiality and source authenticity. Such protection prevents undetected modification that could create a denial-of-service situation. However, it is possible for an adversary to alter the message flows, causing each message to be rejected by the recipient because it fails the integrity checking.
EAPトンネル方式による暗号化認証後、セッションを暗号化して保護し、機密性とソースの信頼性を提供できます。このような保護により、サービス拒否の状況を引き起こす可能性のある未検出の変更が防止されます。ただし、攻撃者がメッセージフローを変更して、各メッセージが整合性チェックに失敗したために受信者に拒否される可能性があります。
As described in Section 3.4 and in the NEA Asokan Attack Analysis [RFC6813], a sophisticated MITM attack can be mounted against NEA systems. The attacker forwards PA-TNC messages from a healthy machine through an unhealthy one so that the unhealthy machine can gain network access. Section 3.4 and [RFC6813] provide a detailed description of this attack and of the countermeasures that can be employed against it.
セクション3.4およびNEA麻生攻撃分析[RFC6813]で説明されているように、洗練されたMITM攻撃をNEAシステムに対して実装できます。攻撃者は、正常なマシンから正常でないマシンを介してPA-TNCメッセージを転送し、異常なマシンがネットワークにアクセスできるようにします。セクション3.4と[RFC6813]は、この攻撃の詳細と、この攻撃に対して採用できる対策について説明しています。
Because lying endpoint attacks are much easier than Asokan attacks and an effective countermeasure against lying endpoint attacks is the use of an External Measurement Agent (EMA), countermeasures against an Asokan attack are not necessary unless an EMA is in use. However, PT-EAP implementers may not know whether an EMA will be used with their implementation. Therefore, PT-EAP implementers SHOULD support these countermeasures by providing the value of the tls-unique channel binding to higher layers in the NEA reference model: Posture Broker Clients, Posture Broker Servers, Posture Collectors, and Posture Validators. If the tls-unique channel binding is implemented, it must be verified before any other attestations are evaluated.
嘘つきエンドポイント攻撃はAsokan攻撃よりもはるかに簡単であり、嘘つきエンドポイント攻撃に対する効果的な対策は外部測定エージェント（EMA）の使用であるため、EMAが使用されていない限り、Asokan攻撃に対する対策は必要ありません。ただし、PT-EAPの実装者は、EMAがその実装で使用されるかどうかわからない場合があります。したがって、PT-EAP実装者は、NEA参照モデルの上位層にポスチャブローカークライアント、ポスチャブローカーサーバー、ポスチャコレクター、ポスチャバリデーターにtls-uniqueチャネルバインディングの値を提供することにより、これらの対策をサポートする必要があります（SHOULD）。 tls固有のチャネルバインディングが実装されている場合は、他の証明書が評価される前に検証する必要があります。
This section discusses how PT-EAP is used within various EAP tunnel methods to meet the PT requirements in Section 5.
このセクションでは、セクション5のPT要件を満たすために、さまざまなEAPトンネル方式内でPT-EAPを使用する方法について説明します。
TEAP [RFC7170], EAP-FAST [RFC4851], and EAP-TTLS [RFC5281] make use of TLS [RFC5246] to protect the transport of information between the NEA Client and NEA Server. Each of these EAP tunnel methods has two phases. In the first phase, a TLS tunnel is established between the NEA Client and NEA Server. In the second phase, the tunnel is used to pass other information. PT-EAP requires that establishing this tunnel include at least an authentication of the NEA Server by the NEA Client.
TEAP [RFC7170]、EAP-FAST [RFC4851]、およびEAP-TTLS [RFC5281]は、TLS [RFC5246]を使用して、NEAクライアントとNEAサーバー間の情報の転送を保護します。これらの各EAPトンネル方式には2つのフェーズがあります。最初のフェーズでは、NEAクライアントとNEAサーバーの間にTLSトンネルが確立されます。 2番目のフェーズでは、トンネルを使用して他の情報を渡します。 PT-EAPでは、このトンネルの確立に、少なくともNEAクライアントによるNEAサーバーの認証が含まれている必要があります。
The phase two dialog may include authentication of the user by doing other EAP methods or, in the case of EAP-TTLS, by using EAP or non-EAP authentication dialogs. PT-EAP is also carried by the phase two tunnel, allowing the NEA assessment to be within an encrypted and integrity-protected transport.
フェーズ2ダイアログには、他のEAP方式によるユーザー認証、またはEAP-TTLSの場合はEAPまたは非EAP認証ダイアログを使用したユーザー認証が含まれる場合があります。 PT-EAPはフェーズ2トンネルでも伝送されるため、NEA評価を暗号化され、整合性が保護されたトランスポート内で行うことができます。
With all these methods (e.g., TEAP [RFC7170], EAP-FAST [RFC4851], and EAP-TTLS [RFC5281]), a cryptographic key is derived from the authentication that may be used to secure later transmissions. Each of these methods employs at least a NEA Server authentication using an X.509 certificate. Within each EAP tunnel method will exist a set of inner EAP methods. These inner methods may perform additional security handshakes including more granular authentications or exchanges of integrity information (such as PT-EAP). At some point after the conclusion of each inner EAP method, some of the methods will export the established secret keys to the outer tunnel method. It's expected that the outer method will cryptographically mix these keys into any keys it is currently using to protect the session and perform a final operation to determine whether both parties have arrived at the same mixed key. This cryptographic binding of the inner method results to the outer method's keys is essential for detection of conventional (non-NEA) Asokan attacks.
これらすべての方法（例：TEAP [RFC7170]、EAP-FAST [RFC4851]、およびEAP-TTLS [RFC5281]）では、暗号化キーは、後の送信を保護するために使用できる認証から導出されます。これらの各方法では、少なくともX.509証明書を使用したNEAサーバー認証を採用しています。各EAPトンネルメソッド内には、一連の内部EAPメソッドが存在します。これらの内部メソッドは、より詳細な認証や完全性情報の交換（PT-EAPなど）を含む、追加のセキュリティハンドシェイクを実行する場合があります。各内部EAP方式の終了後のある時点で、一部の方式は確立された秘密鍵を外部トンネル方式にエクスポートします。外側の方法では、セッションを保護するために現在使用しているキーにこれらのキーを暗号化して混合し、両方のパーティが同じ混合キーに到達したかどうかを判断する最終操作を実行することが期待されます。内部メソッドの結果と外部メソッドのキーのこの暗号バインディングは、従来の（非NEA）麻薬攻撃の検出に不可欠です。
TEAP [RFC7170] is the mandatory-to-implement EAP tunnel method.
TEAP [RFC7170]は、実装が必須のEAPトンネル方式です。
This section summarizes the security claims for this specification, as required by [RFC3748], Section 7.2:
このセクションでは、[RFC3748]のセクション7.2で要求されている、この仕様のセキュリティ要求を要約します。
Auth. mechanism: None
Ciphersuite negotiation: No
Mutual authentication: No
Integrity protection: No
Replay protection: No
Confidentiality: No
Key derivation: No
Key strength: N/A
Dictionary attack resistant: N/A
Fast reconnect: No
Crypt. binding: N/A
Session independence: N/A
Fragmentation: No
Channel binding: No
Because the PT-EAP inner method described in this specification relies on the outer EAP tunnel method for a majority of its security protections, this section reiterates the PT requirements that MUST be met by the IETF standard EAP tunnel method for use with PT-EAP.
この仕様で説明されているPT-EAP内部メソッドは、セキュリティ保護の大部分が外部EAPトンネルメソッドに依存しているため、このセクションでは、PT-EAPで使用するためにIETF標準EAPトンネルメソッドが満たす必要があるPT要件を繰り返し説明します。
TEAP [RFC7170] is a Standards Track EAP tunnel method that satisfies NEA's requirements and is the mandatory-to-implement EAP tunnel method.
TEAP [RFC7170]は、NEAの要件を満たすStandards Track EAPトンネル方式であり、必須から実装までのEAPトンネル方式です。
The security requirements described in this specification MUST be implemented in any product claiming to be PT-EAP compliant. The decision of whether a particular deployment chooses to use these protections is a deployment issue. A customer may choose to avoid potential deployment issues or performance penalties associated with the use of cryptography when the required protection has been achieved through other mechanisms (e.g., physical isolation). If security mechanisms may be deactivated by policy, an implementation SHOULD offer an interface to query how a message will be (or was) protected by PT so higher-layer NEA protocols can factor this into their decisions.
この仕様で説明されているセキュリティ要件は、PT-EAP準拠であると主張するすべての製品に実装する必要があります。特定の展開がこれらの保護の使用を選択するかどうかの決定は、展開の問題です。お客様は、必要な保護が他のメカニズム（物理的な分離など）によって達成された場合、暗号化の使用に関連する潜在的な展開の問題またはパフォーマンスのペナルティを回避することを選択できます。セキュリティメカニズムがポリシーによって非アクティブ化される可能性がある場合、実装は、メッセージがPTによって保護される（または保護される）方法をクエリするためのインターフェイスを提供する必要があります。
RFC 5209 [RFC5209] includes the following requirement that is to be applied during the selection of the EAP tunnel method(s) used in conjunction with PT-EAP:
RFC 5209 [RFC5209]には、PT-EAPと組み合わせて使用されるEAPトンネル方式の選択中に適用される次の要件が含まれています。
PT-2: The PT protocol MUST be capable of supporting mutual authentication, integrity, confidentiality, and replay protection of the PB messages between the Posture Transport Client and the Posture Transport Server.
PT-2：PTプロトコルは、相互認証、完全性、機密性、およびポスチャトランスポートクライアントとポスチャトランスポートサーバー間のPBメッセージのリプレイ保護をサポートできる必要があります。
Note that mutual authentication could be achieved by a combination of a strong authentication of one party (e.g., server authentication while establishing the TLS-based tunnel) by the EAP tunnel method in conjunction with a second authentication of the other party (e.g., client authentication inside the protected tunnel) by another EAP method running prior to PT-EAP.
相互認証は、一方の当事者の強力な認証（たとえば、TLSベースのトンネルを確立するときのサーバー認証）と、もう一方の当事者の2番目の認証（たとえば、クライアント認証）を組み合わせたEAPトンネル方式によって実現できることに注意してください。保護されたトンネル内）PT-EAPの前に実行されている別のEAPメソッドによる。
Having the Posture Transport Client always authenticate the Posture Transport Server provides assurance to the NEA Client that the NEA Server is authentic (not a rogue or MITM) prior to disclosing secret or potentially privacy-sensitive information about what is running or configured on the endpoint. However, the NEA Server's policy may allow for the delay of the authentication of the NEA Client until a suitable protected channel has been established allowing for non-cryptographic NEA Client credentials (e.g., username/password) to be used. Whether the communication channel is established with mutual or server-side-only authentication, the resulting channel needs to provide strong integrity and confidentiality protection to its contents. These protections are to be bound to at least the authentication of the NEA Server by the NEA Client, so the session is cryptographically bound to a particular authentication event.
ポスチャトランスポートクライアントが常にポスチャトランスポートサーバーを認証することで、エンドポイントで実行または構成されているものに関する秘密情報または潜在的にプライバシーに敏感な情報を開示する前に、NEAサーバーがローグまたはMITMではないことを保証します。ただし、NEAサーバーのポリシーでは、適切な保護チャネルが確立されるまでNEAクライアントの認証を遅らせて、暗号化されていないNEAクライアントの資格情報（ユーザー名/パスワードなど）を使用できるようにすることができます。通信チャネルが相互認証またはサーバー側のみの認証で確立されているかどうかに関係なく、結果として生じるチャネルは、コンテンツに強力な整合性と機密保護を提供する必要があります。これらの保護は、少なくともNEAクライアントによるNEAサーバーの認証にバインドされるため、セッションは特定の認証イベントに暗号でバインドされます。
The EAP tunnel method carrying PT-EAP MUST provide strong cryptographic authentication, integrity, and confidentiality protection to protect against NEA assessment message theft as described in Section 4.2.1. The cryptographically protected EAP tunnel ensures that all of the PA-TNC and PB-TNC protocol messages are hidden from intermediaries wanting to steal NEA data.
PT-EAPを伝送するEAPトンネル方式は、セクション4.2.1で説明されているように、NEA評価メッセージの盗難から保護するために、強力な暗号認証、完全性、および機密保護を提供する必要があります。暗号で保護されたEAPトンネルは、PA-TNCおよびPB-TNCプロトコルメッセージのすべてがNEAデータを盗もうとする仲介者から隠されることを保証します。
To support countermeasures against NEA Asokan attacks as described in Section 3.4, the EAP tunnel method used with PT-EAP will need to support generation of the tls-unique value to be used with the higher layers of the NEA reference model. This should not be a high bar since all EAP tunnel methods currently support this, but not all implementations of those methods may do so.
セクション3.4で説明したNEA Asokan攻撃への対策をサポートするには、PT-EAPで使用されるEAPトンネル方式が、NEA参照モデルの上位層で使用されるtls-unique値の生成をサポートする必要があります。現在、すべてのEAPトンネルメソッドがこれをサポートしているため、これは高水準ではありませんが、これらのメソッドのすべての実装がサポートしているわけではありません。
The role of PT-EAP is to act as a secure transport for PB-TNC over a network before the endpoint has been admitted to the network. As a transport protocol, PT-EAP does not directly utilize or require direct knowledge of any personally identifiable information (PII). PT-EAP will typically be used in conjunction with other EAP methods that provide for the user authentication (if bidirectional authentication is used), so the user's credentials are not directly seen by the PT-EAP inner method.
PT-EAPの役割は、エンドポイントがネットワークに許可される前に、ネットワーク上のPB-TNCの安全なトランスポートとして機能することです。トランスポートプロトコルとして、PT-EAPは個人を特定できる情報（PII）を直接利用したり、直接認識したりする必要はありません。 PT-EAPは通常、ユーザー認証を提供する他のEAPメソッドと組み合わせて使用されるため（双方向認証が使用されている場合）、ユーザーの資格情報はPT-EAP内部メソッドによって直接表示されません。
While PT-EAP does not provide cryptographic protection for the PB-TNC batches, it is designed to operate within an EAP tunnel method that provides strong authentication, integrity, and confidentiality services. Therefore, it is important for deployers to leverage these protections in order to prevent disclosure of PII potentially contained within PA-TNC or PB-TNC within the PT-EAP payload.
PT-EAPはPB-TNCバッチに暗号化保護を提供しませんが、強力な認証、整合性、および機密性サービスを提供するEAPトンネル方式内で動作するように設計されています。したがって、PT-EAPペイロード内のPA-TNCまたはPB-TNCに含まれる可能性のあるPIIの開示を防ぐために、展開担当者はこれらの保護を活用することが重要です。
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the PT-EAP protocol, in accordance with BCP 26 [RFC5226].
このセクションでは、BCP 26 [RFC5226]に従って、PT-EAPプロトコルに関連する値の登録に関するInternet Assigned Numbers Authority（IANA）へのガイダンスを提供します。
The EAP Method type for PT-EAP has been assigned value 54, i.e., the assignment for Type in Section 3.3.
PT-EAPのEAPメソッドタイプには、値54、つまりセクション3.3でのタイプの割り当てが割り当てられています。
+-------+----------------------------+-----------+
| Value | Description | Reference |
+-------+----------------------------+-----------+
| 54 | EAP Method Type for PT-EAP | [RFC7171] |
+-------+----------------------------+-----------+
This document also defines one new IANA top-level registry: "PT-EAP Versions". This section explains how this registry works. Because only eight (8) values are available in this registry, a high bar is set for new assignments. The only way to register new values in this registry is through Standards Action (via an approved Standards Track RFC).
このドキュメントでは、1つの新しいIANAトップレベルレジストリ「PT-EAPバージョン」も定義しています。このセクションでは、このレジストリの仕組みについて説明します。このレジストリでは8つの値しか使用できないため、新しい割り当てには高いバーが設定されます。このレジストリに新しい値を登録する唯一の方法は、（承認されたStandards Track RFCを介して）標準アクションを使用することです。
The name for this registry is "PT-EAP Versions". Each entry in this registry includes a decimal integer value between 1 and 7 identifying the version and also includes a reference to the RFC where the version is defined.
このレジストリの名前は「PT-EAPバージョン」です。このレジストリの各エントリには、バージョンを識別する1〜7の10進整数値が含まれ、バージョンが定義されているRFCへの参照も含まれています。
The following entries are defined in this document and are the initial entries in the registry. Additional entries to this registry are added by Standards Action, as defined in RFC 5226 [RFC5226].
次のエントリはこのドキュメントで定義されており、レジストリの最初のエントリです。このレジストリへの追加のエントリは、RFC 5226 [RFC5226]で定義されているように、標準アクションによって追加されます。
+-------+------------------------+
| Value | Defining Specification |
+-------+------------------------+
| 0 | Reserved |
| 1 | [RFC7171] |
+-------+------------------------+
Thanks to the Trusted Computing Group for contributing the initial text upon which this document was based.
このドキュメントの基となった最初のテキストを提供してくれたTrusted Computing Groupに感謝します。
The authors of this document would like to acknowledge the following people who have contributed to or provided substantial input on the preparation of this document or predecessors to it: Amit Agarwal, Morteza Ansari, Diana Arroyo, Stuart Bailey, Boris Balacheff, Uri Blumenthal, Gene Chang, Scott Cochrane, Pasi Eronen, Aman Garg, Sandilya Garimella, David Grawrock, Stephen Hanna, Thomas Hardjono, Chris Hessing, Ryan Hurst, Hidenobu Ito, John Jerrim, Meenakshi Kaushik, Greg Kazmierczak, Scott Kelly, Bryan Kingsford, PJ Kirner, Sung Lee, Lisa Lorenzin, Mahalingam Mani, Bipin Mistry, Seiji Munetoh, Rod Murchison, Barbara Nelson, Kazuaki Nimura, Ron Pon, Ivan Pulleyn, Alex Romanyuk, Ravi Sahita, Joseph Salowey, Chris Salter, Mauricio Sanchez, Dean Sheffield, Curtis Simonson, Jeff Six, Ned Smith, Michelle Sommerstad, Joseph Tardo, Lee Terrell, Susan Thomson, Chris Trytten, and John Vollbrecht.
このドキュメントの作成者は、このドキュメントの作成に貢献したか、このドキュメントの前任者に多大な情報を提供した次の人々を認めたいと思います。AmitAgarwal、Morteza Ansari、Diana Arroyo、Stuart Bailey、Boris Balacheff、Uri Blumenthal、Gene Chang、Scott Cochrane、Pasi Eronen、Aman Garg、Sandilya Garimella、David Grawrock、Stephen Hanna、Thomas Hardjono、Chris Hessing、Ryan Hurst、Hidenobu Ito、John Jerrim、Meenakshi Kaushik、Greg Kazmierczak、Scott Kelly、Bryan Kingsford、PJ Kirner、ソン・リー、リサ・ロレンジン、マハリンガム・マニ、ビピン・ミストリー、宗藤誠司、ロッド・マーチソン、バーバラ・ネルソン、ニムラカズアキ、ロン・ポン、イワン・プーリン、アレックス・ロマニュク、ラビ・サヒタ、ジョセフ・サロウイ、クリス・ソルター、マウリシオ・サンチェス、ディーン・シェフィールド、カーティス・サイモンソン、ジェフ・シックス、ネッド・スミス、ミシェル・ソマースタッド、ジョセフ・タード、リー・テレル、スーザン・トムソン、クリス・トリッテン、ジョン・フォルブレヒト。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J。、およびH. Levkowetz、「Extensible Authentication Protocol（EAP）」、RFC 3748、2004年6月。
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, June 2008.
[RFC5209] Sangster、P.、Khosravi、H.、Mani、M.、Narayan、K。、およびJ. Tardo、「Network Endpoint Assessment（NEA）：Overview and Requirements」、RFC 5209、2008年6月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5792, March 2010.
[RFC5792] Sangster、P。およびK. Narayan、「PA-TNC：A Posture Attribute（PA）Protocol Compatible with Trusted Network Connect（TNC）」、RFC 5792、2010年3月。
[RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5793, March 2010.
[RFC5793] Sahita、R.、Hanna、S.、Hurst、R。、およびK. Narayan、「PB-TNC：A Posture Broker（PB）Protocol Compatible with Trusted Network Connect（TNC）」、RFC 5793、2010年3月。
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, July 2010.
[RFC5929] Altman、J.、Williams、N。、およびL. Zhu、「TLSのチャネルバインディング」、RFC 5929、2010年7月。
[RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, "Tunnel Extensible Authentication Protocol (TEAP) Version 1", RFC 7170, May 2014.
[RFC7170] Zhou、H.、Cam-Winget、N.、Salowey、J。、およびS. Hanna、「Tunnel Extensible Authentication Protocol（TEAP）Version 1」、RFC 7170、2014年5月。
[Asokan] Asokan, N., Niemi, V., Nyberg, K., and Nokia Research Center, Finland, "Man-in-the-Middle Attacks in Tunneled Authentication Protocols", Nov 2002, <http://eprint.iacr.org/2002/163.pdf>.
[Asokan] Asokan、N.、Niemi、V.、Nyberg、K.、Nokia Research Center、フィンランド、「トンネル認証プロトコルにおける中間者攻撃」、2002年11月、<http：// eprint。 iacr.org/2002/163.pdf>。
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)", RFC 4851, May 2007.
[RFC4851] Cam-Winget、N.、McGrew、D.、Salowey、J。、およびH. Zhou、「Secure Tunneling Extensible Authentication Protocol Method（EAP-FAST）による柔軟な認証」、RFC 4851、2007年5月。
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008.
[RFC5281] Funk、P。およびS. Blake-Wilson、「Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0（EAP-TTLSv0）」、RFC 5281、2008年8月。
[RFC6813] Salowey, J. and S. Hanna, "The Network Endpoint Assessment (NEA) Asokan Attack Analysis", RFC 6813, December 2012.
[RFC6813] Salowey、J。およびS. Hanna、「The Network Endpoint Assessment（NEA）Asokan Attack Analysis」、RFC 6813、2012年12月。
[RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture Transport Protocol over TLS (PT-TLS)", RFC 6876, February 2013.
[RFC6876] Sangster、P.、Cam-Winget、N。、およびJ. Salowey、「A Posture Transport Protocol over TLS（PT-TLS）」、RFC 6876、2013年2月。
Authors' Addresses
著者のアドレス
Nancy Cam-Winget Cisco Systems 80 West Tasman Drive San Jose, CA 95134 US
Nancy Cam-Winget Cisco Systems 80 West Tasman Drive San Jose、CA 95134 US
EMail: ncamwing@cisco.com
Paul Sangster Symantec Corporation 6825 Citrine Drive Carlsbad, CA 92009 US
Paul Sangster Symantec Corporation 6825 Citrine Drive Carlsbad、CA 92009 US
EMail: paul_sangster@symantec.com