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
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.
本文件规定了PT-EAP，这是一种基于可扩展身份验证协议（EAP）的姿态传输（PT）协议，设计用于仅在受传输层安全（TLS）保护的EAP隧道方法内使用。本文件还描述了PT-EAP的预期适用性。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/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.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 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
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.
本文件规定了PT-EAP，一种受TLS保护的EAP隧道方法保护的姿态传输（PT）协议。网络端点评估（NEA）体系结构中的PT协议负责在NEA客户端和NEA服务器之间通过网络传输姿态代理（PB-TNC[RFC5793]）批，通常包含姿态属性（PA-TNC[RFC5792]）。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协议旨在用于接入网络端点的入院前评估和网络上已有端点的评估。为了支持这两种使用模型，需要两种类型的PT协议。一种类型的PT，PT-TLS[RFC6876]，在端点具有分配的IP地址后运行，在IP协议之上分层以承载NEA交换。另一种类型的PT在端点获得对IP网络的任何访问之前运行。本规范定义了PT-EAP，PT协议用于在端点访问网络之前评估端点。
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[RFC3748]方法，设计用于受保护隧道内，如隧道EAP（TEAP）[RFC7170]、通过安全隧道的EAP灵活身份验证（EAP-FAST）[RFC4851]或EAP隧道传输层安全（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的一个八位字段的值为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.
本文件重用了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工作组参与者更熟悉这些术语。然而，这些术语在本规范中是等效的。NEA客户端终止PT-EAP的部分（通常在姿态传输客户端中）是PT-EAP的EAP对等方。NEA服务器终止PT-EAP的部分（通常在姿态传输服务器中）是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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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工作的目标之一是提供一套由各方商定的单一终点评估标准。因此，作者了解到，可信计算集团（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设计用于以简单的EAP方法封装PB-TNC批次，该方法可在EAP隧道方法中进行。EAP隧道方法提供机密性和消息完整性，因此PT-EAP不必这样做。因此，必须在基于TLS的EAP隧道方法中使用PT-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验证器（在NEA服务器上终止PT-EAP方法）。
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
本节描述并定义PT-EAP方法。首先，它提供了协议概述。其次，它描述了版本协商等特定功能。第三，它给出了一个详细的数据包
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].
描述最后，它描述了如何使用tls唯一信道绑定[RFC5929]将PA-TNC交换机绑定到EAP隧道方法，从而击败中间人（MITM）攻击，如Asokan攻击[Asokan]。
PT-EAP has two phases that follow each other in strict sequence: negotiation and data transport.
PT-EAP有两个严格顺序的阶段：协商和数据传输。
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.
数据传输阶段是PT-EAP中唯一允许交换PB-TNC批次的阶段。此阶段始终从NEA客户端向NEA服务器发送PB-TNC批开始。然后，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并不意味着成功完成整体身份验证，也不意味着整体失败。这取决于现行的行政政策。
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服务器发送的值。但是，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方法，每条消息中的前四个字段（如图1所示的代码、标识符、长度和类型）由EAP强制执行并在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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
代码字段是一个八位字节，用于标识EAP消息的类型。PT-EAP使用的唯一值为：
1 Request
1请求
2 Response
2回应
Identifier
标识符
The Identifier field is one octet and aids in matching Responses with Requests.
标识符字段是一个八位字节，有助于将响应与请求匹配。
Length
长
The Length field is two octets and indicates the length in octets of this PT-EAP message, starting from the Code field.
长度字段为两个八位字节，表示此PT-EAP消息的长度（以八位字节为单位），从代码字段开始。
Type
类型
54 (EAP Method Type [RFC3748] assignment for PT-EAP).
54（PT-EAP的EAP方法类型[RFC3748]分配）。
Flags
旗帜
+-+-+-+-+-+
|S R R R R|
+-+-+-+-+-+
+-+-+-+-+-+
|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消息中的数据字段的长度可以通过从两个八位组长度字段的值中减去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 Asokan攻击分析[RFC6813]所述，可以针对NEA系统发起复杂的MITM攻击。攻击者通过不健康机器转发来自健康机器的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唯一值），因此没有MITM转发姿态。如果它们不同，则已检测到攻击，姿势验证器的验证应失败。
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客户端可以承载一个EMA，该EMA可用作加密绑定tls唯一内容的手段，该tls唯一内容可以由与EAP服务器接口的姿态验证器进行验证。客户机身份验证特有的tls绑定可防止客户机的消息在其他上下文中使用。这可防止配置不良的客户端无意中损害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方法设计为在EAP隧道方法内运行，该方法能够保护PT-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协议处理元素之间的一些信任关系。以下小节将讨论与NEA参考模型的每个部分相关的信任属性，这些部分直接涉及EAP隧道内PT-EAP协议的处理。
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 不得观察、制造或更改从Position Broker客户端传递下来的PB-TNC批次，以便在网络上传输。
o Transmit on the network any PB-TNC batches passed down from the Posture Broker Client.
o 在网络上传输从姿态代理客户端传递下来的任何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 为网络上发送的Positure Broker客户端PB-TNC批提供配置的安全保护（例如，身份验证、完整性和机密性）。
o Expose the authenticated identity of the Posture Transport Server to the Posture Broker Client.
o 向姿态代理客户端公开姿态传输服务器的经过身份验证的标识。
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批交付给Positure Broker客户端，只要它们受到适当的安全保护。
o Provide a secure, reliable, "in-order delivery", full-duplex transport for the Posture Broker Client's messages.
o 为Positure Broker客户端的消息提供安全、可靠的“按订单交付”全双工传输。
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 不得观察、制造或更改从姿态代理服务器传递下来的PB-TNC批次，以便在网络上传输。
o Transmit on the network any PB-TNC batches passed down from the Posture Broker Server.
o 在网络上传输从姿态代理服务器传递下来的任何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 为网络上发送的姿态代理服务器消息提供配置的安全保护（例如，身份验证、完整性和机密性）。
o Expose the authenticated identity of the Posture Transport Client to the Posture Broker Server.
o 向姿态代理服务器公开姿态传输客户端的经过身份验证的标识。
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
一般来说，PT协议负责为所有NEA协议提供强大的安全保护，因此对PT保护NEA协议消息的能力的任何威胁都可能是非常有害的
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-EAP方法，大部分加密安全性由外部EAP隧道方法提供，并且PT-EAP封装在受保护的隧道中。因此，本节强调了携带PT-EAP的EAP隧道方法需要满足的密码要求，以满足NEA PT要求。
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.
消息传递到姿态代理客户端或姿态代理服务器后，将信任姿态代理正确、安全地处理消息。
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消息通过不受保护的网络链路或跨不受信任的本地软件堆栈发送时，消息的内容可能会被中间方窃取。这种盗窃行为可能导致信息被记录下来供对手将来使用或分析。窃听者观察到的消息可能包含暴露端点安全性中潜在弱点的信息或系统指纹信息，从而降低攻击者对端点实施更可能成功的攻击的能力。窃听者还可能了解有关端点或网络策略的信息，这些信息单独或集体地被视为敏感信息。例如，如果PT-EAP由不提供保密保护的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隧道方法（如EAP-FAST或EAP-TTLS）中传输时，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
网络上或NEA系统内的攻击者可能会引入伪造的PT-EAP消息，以欺骗或创建针对评估方面的拒绝服务。例如，对手可以尝试插入PT-EAP消息，告知NEA服务器端点已完全感染。这可能会导致
device to be blocked from accessing a critical resource, which would be a denial of service.
阻止设备访问关键资源，这将是拒绝服务。
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
在通过EAP隧道方法进行加密身份验证之后，可以对会话进行加密保护，以提供机密性和源真实性。这种保护可防止未被发现
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.
可能造成拒绝服务情况的修改。但是，对手可能会更改消息流，导致收件人拒绝每条消息，因为它无法通过完整性检查。
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 Asokan攻击分析[RFC6813]所述，可以针对NEA系统发起复杂的MITM攻击。攻击者通过不健康机器转发来自健康机器的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唯一通道绑定的价值来支持这些对策：姿态代理客户端、姿态代理服务器、姿态收集器和姿态验证器。如果实现了tls唯一通道绑定，则必须在评估任何其他证明之前对其进行验证。
This section discusses how PT-EAP is used within various EAP tunnel methods to meet the PT requirements in Section 5.
本节讨论如何在各种EAP隧道方法中使用PT-EAP，以满足第5节中的PT要求。
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隧道方法都有两个阶段。在第一阶段，在NEA客户端和NEA服务器之间建立TLS隧道。在第二阶段，隧道用于传递其他信息。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.
第二阶段对话框可以包括通过执行其他EAP方法对用户进行认证，或者在EAP-TTL的情况下，通过使用EAP或非EAP认证对话框对用户进行认证。PT-EAP也由二期隧道进行，允许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）Asokan攻击至关重要。
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
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隧道方法实现其大部分安全保护，因此本节重申了IETF标准EAP隧道方法必须满足的PT要求，以用于PT-EAP。
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要求的标准轨道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的保护，以便更高层的NEA协议可以将此纳入其决策中。
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.
注意，通过EAP隧道方法结合另一方的第二认证（例如，受保护隧道内的客户端认证），一方的强认证（例如，建立基于TLS的隧道时的服务器认证）可以实现相互认证通过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客户端保证，在披露有关端点上运行或配置的秘密或潜在隐私敏感信息之前，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.
如第4.2.1节所述，承载PT-EAP的EAP隧道方法必须提供强大的密码认证、完整性和保密保护，以防止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隧道方法需要支持生成tls唯一值，以便与NEA参考模型的更高层一起使用。这不应该是一个高标准，因为目前所有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协议相关值的注册向互联网分配号码管理局（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] |
+-------+----------------------------+-----------+
+-------+----------------------------+-----------+
| 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).
本文档还定义了一个新的IANA顶级注册表：“PT-EAP版本”。本节介绍此注册表的工作原理。由于此注册表中只有八（8）个值可用，因此会为新分配设置一个高条。在此注册表中注册新值的唯一方法是通过标准操作（通过批准的标准跟踪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之间的十进制整数值，用于标识版本，还包括对定义版本的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] |
+-------+------------------------+
+-------+------------------------+
| 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.
本文件的作者谨向以下人士表示感谢，他们对本文件或其前身的编制做出了贡献或提供了大量投入：阿米特·阿加瓦尔、莫特扎·安萨里、黛安娜·阿罗约、斯图尔特·贝利、鲍里斯·巴拉切夫、乌里·布卢门塔尔、吉恩·张、斯科特·科克伦、帕西·埃隆、阿曼·加格、，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 Pluen，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和John Vollbrecht。
[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，“可扩展身份验证协议（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，“网络端点评估（NEA）：概述和要求”，RFC 52092008年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，“在RFCs中编写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，“传输层安全（TLS）协议版本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：与可信网络连接（TNC）兼容的姿态属性（PA）协议”，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：与可信网络连接（TNC）兼容的姿态代理（PB）协议”，RFC 57932010年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 59292010年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，“隧道可扩展认证协议（TEAP）版本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.，和芬兰诺基亚研究中心，“隧道认证协议中的中间人攻击”，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，“通过安全隧道可扩展认证协议方法（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，“可扩展认证协议隧道传输层安全认证协议版本0（EAP-TTLSv0）”，RFC 52812008年8月。
[RFC6813] Salowey, J. and S. Hanna, "The Network Endpoint Assessment (NEA) Asokan Attack Analysis", RFC 6813, December 2012.
[RFC6813]Salowey，J.和S.Hanna，“网络端点评估（NEA）Asokan攻击分析”，RFC 68132012年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，“TLS上的姿态传输协议（PT-TLS）”，RFC 6876，2013年2月。
Authors' Addresses
作者地址
Nancy Cam-Winget Cisco Systems 80 West Tasman Drive San Jose, CA 95134 US
美国加利福尼亚州圣何塞市西塔斯曼大道80号南希·坎温吉特·思科系统公司，邮编95134
EMail: ncamwing@cisco.com
EMail: ncamwing@cisco.com
Paul Sangster Symantec Corporation 6825 Citrine Drive Carlsbad, CA 92009 US
美国加利福尼亚州卡尔斯巴德Citrine Drive 6825号保罗桑斯特赛门铁克公司，邮编92009
EMail: paul_sangster@symantec.com
EMail: paul_sangster@symantec.com