Internet Engineering Task Force (IETF) P. Sangster
Request for Comments: 6876 Symantec Corporation
Category: Standards Track N. Cam-Winget
ISSN: 2070-1721 J. Salowey
Cisco Systems
February 2013
Internet Engineering Task Force (IETF) P. Sangster
Request for Comments: 6876 Symantec Corporation
Category: Standards Track N. Cam-Winget
ISSN: 2070-1721 J. Salowey
Cisco Systems
February 2013
A Posture Transport Protocol over TLS (PT-TLS)
TLS上的姿态传输协议（PT-TLS）
Abstract
摘要
This document specifies PT-TLS, a TLS-based Posture Transport (PT) protocol. The PT-TLS protocol carries the Network Endpoint Assessment (NEA) message exchange under the protection of a Transport Layer Security (TLS) secured tunnel.
本文件规定了PT-TLS，一种基于TLS的姿态传输（PT）协议。PT-TLS协议在传输层安全（TLS）安全隧道的保护下承载网络端点评估（NEA）消息交换。
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/rfc6876.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6876.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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 ....................................................3
1.1. Prerequisites ..............................................4
1.2. Message Diagram Conventions ................................4
1.3. Conventions Used in This Document ..........................4
1.4. Compatibility with Other Specifications ....................4
2. Design Considerations ...........................................5
2.1. Benefits of TCP/IP Connectivity ............................5
2.2. Leveraging Proven TLS Security .............................6
2.3. TLV-Based Message Encapsulation ............................6
2.4. No Change to Base TLS Protocol .............................6
3. PT-TLS Protocol .................................................7
3.1. Initiating a PT-TLS Session ................................8
3.1.1. Issues with Server-Initiated PT-TLS Sessions ........8
3.1.2. Establish or Re-Use Existing PT-TLS Session .........9
3.2. TCP Port Usage .............................................9
3.3. Preventing MITM Attacks with Channel Bindings ..............9
3.4. PT-TLS Message Flow .......................................10
3.4.1. Assessment Triggers ................................10
3.4.2. PT-TLS Message Exchange Phases .....................11
3.4.2.1. TLS Setup Phase ...........................12
3.4.2.2. PT-TLS Negotiation Phase ..................13
3.4.2.3. PT-TLS Data Transport Phase ...............14
3.4.3. TLS Requirements ...................................14
3.5. PT-TLS Message Format .....................................15
3.6. IETF Namespace PT-TLS Message Types .......................18
3.7. PT-TLS Version Negotiation ................................20
3.7.1. Version Request Message ............................21
3.7.2. Version Response Message ...........................22
3.8. Client Authentication Using SASL ..........................22
3.8.1. SASL Client Authentication Requirements ............23
3.8.2. SASL in PT-TLS Overview ............................24
3.8.3. SASL Authentication Flow ...........................24
3.8.4. Aborting SASL Authentication .......................25
3.8.5. Linkages to SASL Framework .........................25
3.8.5.1. SASL Service Name .........................25
3.8.5.2. SASL Authorization Identity ...............25
3.8.5.3. SASL Security Layer .......................25
3.8.5.4. Multiple Authentications ..................25
3.8.6. SASL Channel Bindings ..............................25
3.8.7. SASL Mechanisms ....................................26
3.8.8. SASL Mechanism Selection ...........................26
3.8.9. SASL Authentication Data ...........................27
3.8.10. SASL Result .......................................28
3.9. Error Message .............................................29
1. Introduction ....................................................3
1.1. Prerequisites ..............................................4
1.2. Message Diagram Conventions ................................4
1.3. Conventions Used in This Document ..........................4
1.4. Compatibility with Other Specifications ....................4
2. Design Considerations ...........................................5
2.1. Benefits of TCP/IP Connectivity ............................5
2.2. Leveraging Proven TLS Security .............................6
2.3. TLV-Based Message Encapsulation ............................6
2.4. No Change to Base TLS Protocol .............................6
3. PT-TLS Protocol .................................................7
3.1. Initiating a PT-TLS Session ................................8
3.1.1. Issues with Server-Initiated PT-TLS Sessions ........8
3.1.2. Establish or Re-Use Existing PT-TLS Session .........9
3.2. TCP Port Usage .............................................9
3.3. Preventing MITM Attacks with Channel Bindings ..............9
3.4. PT-TLS Message Flow .......................................10
3.4.1. Assessment Triggers ................................10
3.4.2. PT-TLS Message Exchange Phases .....................11
3.4.2.1. TLS Setup Phase ...........................12
3.4.2.2. PT-TLS Negotiation Phase ..................13
3.4.2.3. PT-TLS Data Transport Phase ...............14
3.4.3. TLS Requirements ...................................14
3.5. PT-TLS Message Format .....................................15
3.6. IETF Namespace PT-TLS Message Types .......................18
3.7. PT-TLS Version Negotiation ................................20
3.7.1. Version Request Message ............................21
3.7.2. Version Response Message ...........................22
3.8. Client Authentication Using SASL ..........................22
3.8.1. SASL Client Authentication Requirements ............23
3.8.2. SASL in PT-TLS Overview ............................24
3.8.3. SASL Authentication Flow ...........................24
3.8.4. Aborting SASL Authentication .......................25
3.8.5. Linkages to SASL Framework .........................25
3.8.5.1. SASL Service Name .........................25
3.8.5.2. SASL Authorization Identity ...............25
3.8.5.3. SASL Security Layer .......................25
3.8.5.4. Multiple Authentications ..................25
3.8.6. SASL Channel Bindings ..............................25
3.8.7. SASL Mechanisms ....................................26
3.8.8. SASL Mechanism Selection ...........................26
3.8.9. SASL Authentication Data ...........................27
3.8.10. SASL Result .......................................28
3.9. Error Message .............................................29
4. Security Considerations ........................................32
4.1. Trust Relationships .......................................32
4.1.1. Posture Transport Client ...........................33
4.1.2. Posture Transport Server ...........................34
4.2. Security Threats and Countermeasures ......................35
4.2.1. Message Theft ......................................35
4.2.2. Message Fabrication ................................36
4.2.3. Message Modification ...............................36
4.2.4. Denial of Service ..................................37
4.2.5. NEA Asokan Attacks .................................37
4.2.6. Trust Anchors ......................................38
5. Privacy Considerations .........................................38
6. IANA Considerations ............................................38
6.1. Designated Expert Guidelines ..............................39
6.2. Registry for PT-TLS Message Types .........................40
6.3. Registry for PT-TLS Error Codes ...........................41
7. Acknowledgments ................................................41
8. References .....................................................42
8.1. Normative References ......................................42
8.2. Informative References ....................................43
4. Security Considerations ........................................32
4.1. Trust Relationships .......................................32
4.1.1. Posture Transport Client ...........................33
4.1.2. Posture Transport Server ...........................34
4.2. Security Threats and Countermeasures ......................35
4.2.1. Message Theft ......................................35
4.2.2. Message Fabrication ................................36
4.2.3. Message Modification ...............................36
4.2.4. Denial of Service ..................................37
4.2.5. NEA Asokan Attacks .................................37
4.2.6. Trust Anchors ......................................38
5. Privacy Considerations .........................................38
6. IANA Considerations ............................................38
6.1. Designated Expert Guidelines ..............................39
6.2. Registry for PT-TLS Message Types .........................40
6.3. Registry for PT-TLS Error Codes ...........................41
7. Acknowledgments ................................................41
8. References .....................................................42
8.1. Normative References ......................................42
8.2. Informative References ....................................43
The NEA architecture [RFC5209] defines a system for communicating posture between a client, where it is collected, and server, where it is assessed. Posture is configuration and/or status of hardware or software on an endpoint as it pertains to an organization's security policy. This document specifies PT-TLS, a TLS-based Posture Transport (PT) protocol protected by a TLS channel.
NEA体系结构[RFC5209]定义了一个系统，用于在收集信息的客户端和评估信息的服务器之间进行通信。姿态是端点上硬件或软件的配置和/或状态，因为它与组织的安全策略有关。本文件规定了PT-TLS，一种受TLS通道保护的基于TLS的姿态传输（PT）协议。
NEA protocols are intended to be used for pre-admission assessment of endpoints joining the network and to assess endpoints already present on the network. In order to support both usage models, two different types (or bindings) of PT protocols are necessary to operate before and after the endpoint has an assigned IP address and other network-layer information. This specification focuses on the PT protocol used to assess endpoints already present on the network and thus is able to use TCP/IP-based transport protocols. NEA has defined another protocol called PT-EAP [PT-EAP] to address assessment prior to the endpoint having an assigned IP address.
NEA协议旨在用于接入网络的端点的入院前评估，以及评估网络上已经存在的端点。为了支持这两种使用模型，需要在端点具有指定的IP地址和其他网络层信息之前和之后操作两种不同类型（或绑定）的PT协议。本规范侧重于用于评估网络上已有端点的PT协议，因此能够使用基于TCP/IP的传输协议。NEA定义了另一个称为PT-EAP[PT-EAP]的协议，以在端点具有指定IP地址之前解决评估问题。
The Posture Transport protocol in the NEA architecture [RFC5209] is responsible for transporting Posture Broker (PB-TNC [RFC5793]) batches, often containing Posture Attributes (PA-TNC [RFC5792]) over the network between the Posture Transport Client component of the NEA Client and the Posture Transport Server component of the NEA Server.
NEA体系结构[RFC5209]中的姿态传输协议负责通过网络在NEA客户端的姿态传输客户端组件和NEA服务器的姿态传输服务器组件之间传输姿态代理（PB-TNC[RFC5793]）批，通常包含姿态属性（PA-TNC[RFC5792]）。
The PT protocol also offers strong security protections to ensure that the exchanged messages are protected from a variety of threats from hostile intermediaries.
PT协议还提供了强大的安全保护，以确保交换的消息受到保护，免受来自敌对中介的各种威胁。
This document does not define an architecture or reference model. Instead, it defines one binding of the PT protocol that works within the reference model described in the NEA Overview and Requirements specification [RFC5209]. The reader is assumed to be thoroughly familiar with [RFC5209]. The NEA working group compared the functionality described in this specification with the requirements in [RFC5209] and found that each applicable requirement was addressed.
本文档未定义架构或参考模型。相反，它定义了PT协议的一个绑定，该绑定在NEA概述和需求规范[RFC5209]中描述的参考模型内工作。假定读者完全熟悉[RFC5209]。NEA工作组将本规范中描述的功能与[RFC5209]中的要求进行了比较，发现每个适用的要求都得到了满足。
This specification defines the syntax of PT-TLS 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-TLS消息的语法。每个图表以位为单位描述每个字段的格式和大小。实现必须按照所示发送每个图中的位，从上到下遍历图，然后在每行中从左到右遍历（表示32位的数量）。表示数值的多字节字段必须以网络（大端）字节顺序发送。
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。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "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规范等效且可互操作的新版本取代其现有的姿态传输协议。
This section discusses some of the key design considerations for the PT protocol. This document specifies the PT binding for use when performing an assessment or reassessment after the endpoint has been admitted to the network and is capable of using TCP/IP to communicate with the NEA Server. If the endpoint does not yet have TCP/IP-layer access to the NEA Server (and vice versa), the endpoint can use the PT-EAP (Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP) Tunnel Methods) protocol when performing an assessment.
本节讨论PT协议的一些关键设计注意事项。本文档规定了在端点被允许进入网络并能够使用TCP/IP与NEA服务器通信后，在执行评估或重新评估时使用的PT绑定。如果端点尚未具有对NEA服务器的TCP/IP层访问权限（反之亦然），则在执行评估时，端点可以使用PT-EAP（可扩展身份验证协议（EAP）隧道方法的姿态传输（PT）协议）协议。
Because the endpoint has TCP/IP access to the NEA Server (potentially on a restricted portion of the network), the NEA Client and NEA Server have the ability to establish (or re-use) a reliable TCP/IP connection in order to perform the assessment. The TCP/IP connection enables the assessment to occur over a relatively high-performance, reliable channel capable of supporting multiple roundtrip message exchanges in a full-duplex manner. These connection properties are very different from what is available when the endpoint is initially joining the network (e.g., during an 802.1X-based assessment); therefore, the design described in this specification follows a different path to maximize the benefits of the underlying TCP/IP connection.
由于端点可以通过TCP/IP访问NEA服务器（可能在网络的受限部分），因此NEA客户端和NEA服务器能够建立（或重新使用）可靠的TCP/IP连接，以便执行评估。TCP/IP连接使评估能够在能够以全双工方式支持多个往返消息交换的相对高性能、可靠的信道上进行。这些连接属性与端点最初加入网络时（例如，在基于802.1X的评估期间）可用的连接属性非常不同；因此，本规范中描述的设计遵循不同的路径，以最大化底层TCP/IP连接的好处。
The PT protocol over TLS is typically able to offer to the NEA Client and NEA Server significantly higher quality of service and flexibility of operation than PT-EAP. However, there may be some added risks when the endpoint is on the network prior to its initial assessment (if no admission time assessment had been performed). Because of these risks, the combined use of an EAP-based assessment during admission followed by reassessment using TCP/IP may be appropriate in some environments.
TLS上的PT协议通常能够向NEA客户端和NEA服务器提供比PT-EAP更高的服务质量和操作灵活性。然而，当终点在其初始评估之前在网络上时（如果没有执行入院时间评估），可能会有一些额外的风险。由于这些风险，在某些环境中，在入院期间结合使用基于EAP的评估，然后使用TCP/IP重新评估可能是合适的。
Some of the benefits to having a TCP/IP-based transport during an assessment include:
评估期间使用基于TCP/IP的传输的一些好处包括：
o Full-Duplex Connectivity - used to support asynchronous initiation of posture exchanges within a single TLS connection (e.g., triggered by alerts of posture or policy changes)
o 全双工连接-用于支持在单个TLS连接内异步启动姿态交换（例如，由姿态或策略更改警报触发）
o High Bandwidth - potentially much higher bandwidth than other transports (e.g., EAP), allowing more in-band data (e.g., remediation, verbose posture information)
o 高带宽-可能比其他传输（如EAP）的带宽高得多，允许更多带内数据（如修复、详细姿态信息）
o Large Messages - ability to send very large Posture Attribute messages without directly fragmenting them (underlying carrier protocol may introduce fragmentation)
o 大消息-能够发送非常大的姿态属性消息，而无需直接对其进行分段（底层运营商协议可能会引入分段）
o Bidirectional - NEA Client and NEA Server can initiate an assessment or reassessment
o 双向-NEA客户端和NEA服务器可以启动评估或重新评估
o Multiple Roundtrips - NEA Client and NEA Server can exchange numerous messages without fear of infrastructure timeouts. However, the entire exchange should be kept as brief as possible if the user has to wait for its completion.
o 多次往返-NEA客户端和NEA服务器可以交换大量消息，而无需担心基础设施超时。但是，如果用户必须等待交换完成，则整个交换应尽可能简短。
All PT protocol bindings must be capable of providing strong authentication, integrity, and confidentiality protection for the PB-TNC batches. Rather than define a new protocol over TCP/IP to provide adequate protection, this specification requires the use of Transport Layer Security [RFC5246] to secure the connection. TLS was selected because it's a widely deployed protocol with parallel protections to a number of the EAP tunnel methods, and it meets all of the security requirements.
所有PT协议绑定必须能够为PB-TNC批提供强大的身份验证、完整性和机密性保护。本规范要求使用传输层安全[RFC5246]来保护连接，而不是定义TCP/IP上的新协议以提供足够的保护。之所以选择TLS，是因为它是一种广泛部署的协议，对许多EAP隧道方法具有并行保护，并且它满足所有安全要求。
The design of the PT-TLS protocol is based upon the use of a type-length-value (TLV)-oriented protocol message that identifies the type of message, the message's length, and a potentially variable-length payload value. The use of a TLV-oriented encoding was chosen to match the Internet standard PA-TNC and PB-TNC protocols. Because the PA-TNC, PB-TNC, and PT-TLS protocols are typically implemented inside the same process space, this allows a common set of message-parsing code to be used. Similarly, creation of debugging tools is simplified by the common encoding methodologies. TLV-based encoding was used in each of the NEA protocols in part because it enables a very space-efficient representation on the network and is simpler to parse than some other encodings to benefit lower-powered (or battery constrained) devices.
PT-TLS协议的设计基于使用面向类型长度值（TLV）的协议消息，该消息标识消息类型、消息长度和潜在可变长度有效负载值。选择使用面向TLV的编码来匹配互联网标准PA-TNC和PB-TNC协议。由于PA-TNC、PB-TNC和PT-TLS协议通常在同一进程空间内实现，因此允许使用一组通用的消息解析代码。类似地，通用编码方法简化了调试工具的创建。每个NEA协议中都使用了基于TLV的编码，部分原因是它能够在网络上实现非常节省空间的表示，并且比其他一些编码更易于解析，从而有利于低功耗（或电池受限）设备。
During the design of the PT-TLS protocol, several approaches were considered with different costs and benefits. Several considered approaches involved integrating the PT protocol into the TLS handshake protocol. Because the PT protocol requires the underlying TLS carrier to provide security protections, the PT protocol couldn't operate before the cipher suites were negotiated and in use. One option was to integrate into the TLS handshake protocol after the
在PT-TLS协议的设计过程中，考虑了几种成本和收益不同的方法。考虑的几种方法涉及将PT协议集成到TLS握手协议中。由于PT协议要求底层TLS运营商提供安全保护，因此在协商和使用密码套件之前，PT协议无法运行。一种选择是在测试结束后集成到TLS握手协议中
ChangeCipherSpec phase, allowing the PT message to be protected. The benefit of this approach is that the assessment protocol could operate below the application protocols, allowing for easier integration into applications. However, making this change would require some extensions to the TLS handshake protocol standards and existing widely deployed TLS implementations, so it wasn't clear that the cost was warranted, particularly because the application independence can also be offered by a shim library between the application and TLS library that provides the PT protocol encapsulation/decapsulation.
ChangeCipherSpec阶段，允许保护PT消息。这种方法的好处是，评估协议可以在应用程序协议下运行，从而更容易集成到应用程序中。然而，做出这一改变需要对TLS握手协议标准和现有广泛部署的TLS实现进行一些扩展，因此不清楚成本是否合理，特别是因为应用程序和提供PT协议封装/去封装的TLS库之间的垫片库也可以提供应用程序独立性。
The other general approach considered was to have PT-TLS layer on top of TLS as an application protocol (using the standard application_data ContentType). This has the advantage that existing TLS software could be used. However, the PB-TNC traffic would need to be encapsulated/decapsulated by a new PT-TLS protocol layer before being passed to the TLS library. This didn't seem like a significant issue, as PB-TNC is architected to layer on PT anyway.
考虑的另一种通用方法是将PT-TLS层置于TLS之上，作为应用程序协议（使用标准的application_data ContentType）。这样做的优点是可以使用现有的TLS软件。但是，PB-TNC通信量在传递到TLS库之前需要由新的PT-TLS协议层进行封装/解封。这似乎不是一个重要的问题，因为PB-TNC的架构是在PT上分层的。
After considering the different options, it was determined that layering the PT protocol on top of the TLS protocol without requiring current TLS protocol implementations to change met all the requirements and offered the best path toward rapid adoption and deployment. Therefore, the following sections describe a PT protocol that is carried on top of TLS.
在考虑不同的选项后，确定在TLS协议之上分层PT协议而不需要更改当前的TLS协议实现符合所有要求，并提供了快速采用和部署的最佳路径。因此，以下各节描述了在TLS之上执行的PT协议。
This section specifies the PT-TLS protocol, a Posture Transport (PT) protocol carried by the Transport Layer Security (TLS) protocol over a TCP/IP network. As shown in Figure 1, this protocol runs directly on top of TLS as an application. This means PT-TLS is encapsulated within the TLS Record Layer protocol using the standard ContentType for applications (application_data).
本节规定了PT-TLS协议，即传输层安全（TLS）协议通过TCP/IP网络承载的姿态传输（PT）协议。如图1所示，该协议作为应用程序直接在TLS之上运行。这意味着PT-TLS使用标准ContentType for applications（application_数据）封装在TLS记录层协议中。
+---------------------------------------------------------------+
| TLV Encapsulation of PB-PA message |
+---------------------------------------------------------------+
| TLS |
+---------------------------------------------------------------+
| TCP |
+---------------------------------------------------------------+
+---------------------------------------------------------------+
| TLV Encapsulation of PB-PA message |
+---------------------------------------------------------------+
| TLS |
+---------------------------------------------------------------+
| TCP |
+---------------------------------------------------------------+
Figure 1. PT-TLS Layering Model
图1。PT-TLS分层模型
The PT-TLS protocol may be initiated by a Posture Transport Client or a Posture Transport Server. This flexibility supports different use cases. For example, a Posture Transport Client that wishes to trigger a NEA assessment to determine whether its security posture is good can start up a PT-TLS session and request a posture assessment. On the other hand, when an endpoint requests access to a protected network or resource, a Posture Transport Server can start up a PT-TLS session and perform a posture assessment before deciding whether to grant access.
PT-TLS协议可由姿态传输客户端或姿态传输服务器发起。这种灵活性支持不同的用例。例如，希望触发NEA评估以确定其安全态势是否良好的态势传输客户端可以启动PT-TLS会话并请求态势评估。另一方面，当端点请求访问受保护的网络或资源时，姿态传输服务器可以启动PT-TLS会话并在决定是否授予访问权限之前执行姿态评估。
The party that initiates a PT-TLS session is known as the "PT-TLS Initiator". The other party in the session (which receives the request to open a PT-TLS session) is known as the "PT-TLS Responder".
发起PT-TLS会话的一方称为“PT-TLS启动器”。会话中的另一方（接收打开PT-TLS会话的请求）称为“PT-TLS响应者”。
In order for a NEA Server to establish a PT-TLS session, the NEA Client needs to be listening for a connection request on a TCP port known by the NEA Server. In many deployments, the security policies of an endpoint (e.g., firewall software) or the security policies of a network (e.g., firewall devices) are designed to minimize the number of open inbound TCP/UDP ports that are available to the network to reduce the potential attack footprint. This is one issue that makes it difficult for a NEA Server to initiate a PT-TLS session.
为了使NEA服务器建立PT-TLS会话，NEA客户端需要在NEA服务器已知的TCP端口上侦听连接请求。在许多部署中，端点的安全策略（例如，防火墙软件）或网络的安全策略（例如，防火墙设备）设计用于最小化网络可用的开放入站TCP/UDP端口的数量，以减少潜在的攻击足迹。这是一个使NEA服务器难以启动PT-TLS会话的问题。
Another issue with this scenario involves X.509 certificates. When the NEA Server creates a TLS session to the NEA Client, the NEA Client is effectively acting as the TLS server during the TLS protocol exchange. This means the NEA Client would typically need to possess an X.509 certificate to protect the initial portion of the TLS handshake. In situations where the NEA Server initiates the creation of the TLS session, both the NEA Client and NEA Server MUST possess X.509 certificates to fully authenticate the session. For many deployments, provisioning X.509 certificates to all NEA Clients has scalability and cost issues; therefore, it is recommended that the NEA Client not listen for connection requests from the NEA Server but instead establish and maintain a TLS session to the NEA Server proactively, so either party can initiate an assessment using the preexisting TLS session as required.
此场景的另一个问题涉及X.509证书。当NEA服务器创建与NEA客户端的TLS会话时，NEA客户端在TLS协议交换期间有效地充当TLS服务器。这意味着NEA客户端通常需要拥有X.509证书来保护TLS握手的初始部分。在NEA服务器启动TLS会话创建的情况下，NEA客户端和NEA服务器都必须拥有X.509证书才能完全验证会话。对于许多部署，向所有NEA客户端提供X.509证书存在可扩展性和成本问题；因此，建议NEA客户端不要侦听来自NEA服务器的连接请求，而是主动建立和维护到NEA服务器的TLS会话，以便任何一方都可以根据需要使用先前存在的TLS会话启动评估。
In most cases, the traditional methods of server certificate ID validation will not apply when the NEA Server initiates the connection. In this case, the NEA Client and Server need to follow the certificate path validation rules in RFC 5280 [RFC5280]. In
在大多数情况下，当NEA服务器启动连接时，传统的服务器证书ID验证方法将不适用。在这种情况下，NEA客户端和服务器需要遵循RFC 5280[RFC5280]中的证书路径验证规则。在里面
addition, each side needs to be able to authorize its peer based upon matching Subject and SubjectAltName fields for certificates issued by a particular trust anchor.
此外，每一方都需要能够基于特定信任锚颁发的证书的匹配Subject和SubjectAltName字段来授权其对等方。
Therefore, NEA Clients SHOULD be capable of establishing and holding open a TLS session with the NEA Server immediately after obtaining network access. A NEA Client MAY listen for connection requests from the NEA Server and establish a new PT-TLS session when one does not already exist. Because of the potential added complexity, a NEA Client's support for accepting inbound PT-TLS connections is optional to implement. Having an existing PT-TLS session allows either party to initiate an assessment without requiring the NEA Client to be listening for new connection requests. In order to keep the TLS session alive, the NEA Client and NEA Server SHOULD be capable of supporting the TLS heartbeat protocol [RFC6520].
因此，NEA客户端应能够在获得网络访问权后立即建立并保持与NEA服务器的TLS会话。NEA客户端可以侦听来自NEA服务器的连接请求，并在尚未建立新的PT-TLS会话时建立新的PT-TLS会话。由于可能增加的复杂性，NEA客户端对接受入站PT-TLS连接的支持是可选的。现有PT-TLS会话允许任何一方启动评估，而无需NEA客户端监听新的连接请求。为了使TLS会话保持活动状态，NEA客户端和NEA服务器应能够支持TLS心跳协议[RFC6520]。
A single PT-TLS session can support multiple NEA assessments, which can be started by either party (the PT-TLS Initiator or the PT-TLS Responder). The party that starts a NEA assessment is known as the "assessment initiator", and the other party is known as the "assessment responder".
单个PT-TLS会话可支持多个NEA评估，可由任何一方（PT-TLS发起方或PT-TLS响应方）启动。开始NEA评估的一方称为“评估发起人”，另一方称为“评估响应者”。
If the assessment initiator already has a PT-TLS session to the assessment responder, the initiator can re-use this session; otherwise, a new PT-TLS session needs to be established.
如果评估发起人已经与评估响应人建立了PT-TLS会话，则发起人可以重新使用该会话；否则，需要建立新的PT-TLS会话。
In order for a PT-TLS Initiator to establish a TCP connection to a PT-TLS Responder, the initiator needs to know the TCP port number on which the responder is listening for assessment requests. The IANA has reserved TCP port number 271 for use by "pt-tls".
为了让PT-TLS启动器与PT-TLS响应程序建立TCP连接，启动器需要知道响应程序正在侦听评估请求的TCP端口号。IANA已保留TCP端口号271供“pt tls”使用。
As described in "The Network Endpoint Assessment (NEA) Asokan Attack Analysis" [RFC6813], a sophisticated Man-in-the-Middle (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, the Posture Broker Client on an EMA-equipped endpoint should pass the tls-unique channel binding [RFC5929] for PT-TLS's underlying TLS session to the EMA. This value can then be included in the EMA's attestation, and the Posture Validator responsible for communicating with the EMA may then confirm that the value matches the tls-unique channel binding for its end of the connection. If the values match, the posture sent by the EMA and 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 man-in-the-middle is forwarding posture. If they differ, the Asokan attack has been detected. The Posture Validator MUST fail its verification of the endpoint if the Asokan attack has been detected.
为防止NEA Asokan攻击，配备EMA的端点上的姿态代理客户端应将PT-tls底层tls会话的tls唯一通道绑定[RFC5929]传递给EMA。然后，该值可以包含在EMA的认证中，并且负责与EMA通信的姿势验证器随后可以确认该值与连接端的tls唯一通道绑定相匹配。如果值匹配，EMA和NEA客户端发送的姿势与TLS连接的客户端来自同一端点（因为端点知道TLS唯一值），因此中间没有人转发姿势。如果他们不同意，那么麻生袭击已经被发现。如果检测到Asokan攻击，姿态验证器必须通过端点验证。
This section discusses the general flow of messages between the NEA Client's Posture Transport Client and the NEA Server's Posture Transport Server in order to perform NEA assessments using the PT-TLS protocol.
本节讨论NEA客户端姿态传输客户端和NEA服务器姿态传输服务器之间的一般消息流，以便使用PT-TLS协议执行NEA评估。
Initially, the NEA Client or NEA Server will decide that an assessment is needed. What stimulates the decision to perform an assessment is outside the scope of this specification, but some examples include:
最初，NEA客户端或NEA服务器将决定需要进行评估。促使做出评估决定的因素不在本规范范围内，但一些示例包括：
o NEA Server becoming aware of suspicious behavior on an endpoint
o NEA服务器意识到端点上的可疑行为
o NEA Server receiving new policies requiring immediate action
o NEA服务器接收到需要立即采取行动的新策略
o NEA Client noticing a change in local security posture
o NEA客户注意到当地安全态势的变化
o NEA Client wishing to access a protected network or resource
o 希望访问受保护网络或资源的NEA客户端
Because either the NEA Client or NEA Server can trigger the establishment of the TLS session and initiate the assessment, this document will use the terms "assessment initiator" and "assessment responder". This nomenclature allows either NEA component to fill either of the PT-TLS roles.
由于NEA客户端或NEA服务器均可触发TLS会话的建立并启动评估，因此本文件将使用术语“评估发起人”和“评估响应人”。该命名法允许NEA组件担任PT-TLS角色。
The PT-TLS message exchange occurs in three distinct phases:
PT-TLS消息交换分三个不同阶段进行：
o TLS Setup (including TLS handshake protocol)
o TLS设置（包括TLS握手协议）
o PT-TLS Negotiation
o PT-TLS谈判
o PT-TLS Data Transport
o PT-TLS数据传输
The TLS Setup phase is responsible for the establishment of the TCP connection and the TLS protections for the PT-TLS messages. The TLS Setup phase starts with the establishment of a TCP connection between the Posture Transport Client and Posture Transport Server. The new connection triggers the TLS server to start the TLS handshake protocol to establish the cryptographic protections for the session. Once the TLS Setup phase has completed (after the TLS Finished messages), the TLS session MUST NOT be renegotiated. TLS session renegotiation MAY be used before the TLS Setup phase ends and the PT-TLS Negotiation phase begins. This phase also enables the establishment of the tls-unique shared secret. The tls-unique shared secret can later be used by the PA protocol to protect against some forms of man-in-the-middle attacks.
TLS设置阶段负责建立TCP连接和PT-TLS消息的TLS保护。TLS设置阶段从姿态传输客户端和姿态传输服务器之间建立TCP连接开始。新连接触发TLS服务器启动TLS握手协议，为会话建立加密保护。一旦TLS设置阶段完成（在TLS完成消息之后），不得重新协商TLS会话。TLS会话重新协商可在TLS设置阶段结束和PT-TLS协商阶段开始之前使用。此阶段还允许建立tls唯一共享密钥。tls唯一共享秘密稍后可由PA协议用于防止某些形式的中间人攻击。
The PT-TLS Negotiation phase is only performed at the start of the first assessment on a TLS session. During this phase, the NEA Client and NEA Server discover each other's PT-TLS capabilities and establish a context that will apply to all future PT-TLS messages sent over the TLS session. The PT-TLS Negotiation phase MUST NOT be repeated after the session has entered the Data Transport phase. NEA assessment messages (PB-TNC batches) MUST NOT be sent by the NEA Client or NEA Server prior to the completion of the PT-TLS Negotiation phase to ensure that the security protections for the session are properly established and applied to the NEA assessment messages.
PT-TLS协商阶段仅在TLS会话的第一次评估开始时执行。在此阶段，NEA客户端和NEA服务器将发现彼此的PT-TLS功能，并建立一个上下文，该上下文将应用于通过TLS会话发送的所有未来PT-TLS消息。在会话进入数据传输阶段后，PT-TLS协商阶段不得重复。在PT-TLS协商阶段完成之前，NEA客户端或NEA服务器不得发送NEA评估消息（PB-TNC批处理），以确保会话的安全保护已正确建立并应用于NEA评估消息。
Finally, the Data Transport phase allows the NEA Client and NEA Server to exchange PT messages under the protection of the TLS session consistent with the capabilities established in earlier phases. The exchanged messages can be a PT-TLS protected NEA assessment as described in this specification or other vendor-defined PT-TLS exchanged messages.
最后，数据传输阶段允许NEA客户端和NEA服务器在TLS会话的保护下交换PT消息，这与早期阶段建立的功能一致。交换的消息可以是本规范中所述的PT-TLS保护NEA评估或其他供应商定义的PT-TLS交换消息。
After a new TCP connection is established between the Posture Transport Client and Posture Transport Server, a standard TLS exchange is performed to negotiate a common security context for protecting subsequent communications. As discussed in Section 3.1, the TCP connection establishment and/or the TLS handshake protocol could be initiated by either the NEA Client or NEA Server. The most common situation would be for the assessment initiator to trigger the creation of the TCP connection and TLS handshake, so an assessment could begin when no session already exists. When the NEA Server has initiated the TLS Setup, the NEA Server is acting as a TLS client and the NEA Client is the TLS server (accepting the inbound TLS session request). The expected normal case is that the NEA Client initiates this phase, so that the NEA Server is acting as the TLS server and therefore the bootstrapping of the security of the TLS session is using the NEA Server's certificate. Having the NEA Client initiate the TLS session avoids the need for the NEA Client to also possess a certificate.
在姿态传输客户端和姿态传输服务器之间建立新的TCP连接后，将执行标准TLS交换，以协商公共安全上下文以保护后续通信。如第3.1节所述，TCP连接建立和/或TLS握手协议可由NEA客户端或NEA服务器启动。最常见的情况是评估发起人触发TCP连接和TLS握手的创建，因此评估可以在没有会话存在时开始。当NEA服务器启动TLS设置时，NEA服务器充当TLS客户端，而NEA客户端就是TLS服务器（接受入站TLS会话请求）。预期的正常情况是NEA客户端启动此阶段，因此NEA服务器充当TLS服务器，因此TLS会话的安全性引导使用NEA服务器的证书。让NEA客户端启动TLS会话可以避免NEA客户端也需要拥有证书。
During the TLS Setup phase of PT-TLS, the PT-TLS Initiator contacts the listening port of the PT-TLS Responder and performs a TLS handshake. The PT-TLS Responder MUST possess a trustworthy X.509 certificate used to authenticate to the PT-TLS Initiator and used to bootstrap the security protections of the TLS session. The PT-TLS Initiator MAY also use an X.509 certificate to authenticate to the PT-TLS Responder providing for a bidirectional authentication of the PT-TLS session. The NEA Client MUST provide certificate validation according to the rules in RFC 5280 when evaluating the server certificate. The NEA Client MAY perform certificate revocation checking on the NEA Server's certificate. This specification allows the NEA Client implementation to decide on what certificate revocation technique is to be implemented. If revocation information is not provided in a TLS handshake extension, then clients performing certificate validation will require some network access (e.g., HTTP) to be allowed during the assessment. NEA Client network access to other non-essential services might be restricted during assessments in some situations. If the client cannot access the status information, then its policy may prevent it from completing the TLS handshake.
在PT-TLS的TLS设置阶段，PT-TLS启动器联系PT-TLS响应程序的侦听端口并执行TLS握手。PT-TLS响应程序必须拥有可靠的X.509证书，用于向PT-TLS启动器进行身份验证，并用于引导TLS会话的安全保护。PT-TLS发起方还可以使用X.509证书向PT-TLS响应方进行认证，以提供PT-TLS会话的双向认证。评估服务器证书时，NEA客户端必须根据RFC 5280中的规则提供证书验证。NEA客户端可以对NEA服务器的证书执行证书吊销检查。此规范允许NEA客户端实现决定要实现的证书吊销技术。如果TLS握手扩展中未提供撤销信息，则执行证书验证的客户端将要求在评估期间允许某些网络访问（例如HTTP）。在某些情况下，在评估期间，NEA客户端网络对其他非必要服务的访问可能会受到限制。如果客户端无法访问状态信息，则其策略可能会阻止其完成TLS握手。
In addition, the NEA Client MUST follow the recommendations in RFC 6125 [RFC6125] when validating the NEA Server domain name against the contents of the server certificate, taking into consideration the following restrictions:
此外，在根据服务器证书内容验证NEA服务器域名时，NEA客户端必须遵循RFC 6125[RFC6125]中的建议，并考虑以下限制：
o Any SRV-IDs and URI-IDs in the certificate are ignored.
o 证书中的任何SRV ID和URI ID都将被忽略。
o Use of CN-IDs in certificates is NOT RECOMMENDED.
o 不建议在证书中使用CN ID。
o Wildcards MUST NOT appear in the DNS-ID or CN-ID of a certificate identifying a PT-TLS server.
o 通配符不得出现在标识PT-TLS服务器的证书的DNS-ID或CN-ID中。
Details for the reverse direction are given in Section 3.1.
第3.1节给出了反向的详细信息。
Due to deployment issues with issuing and distributing certificates to a potentially large number of NEA Clients, this specification allows the NEA Client to be authenticated during the PT-TLS Negotiation phase using other more cost-effective methods, as described in Section 3.8.1. At the conclusion of a successful initial TLS Setup phase, the NEA Client and NEA Server have a protected session to exchange messages. This allows the protocol to transition to the PT-TLS Negotiation phase.
由于向可能大量的NEA客户端颁发和分发证书存在部署问题，本规范允许在PT-TLS协商阶段使用其他更具成本效益的方法对NEA客户端进行身份验证，如第3.8.1节所述。在成功的初始TLS设置阶段结束时，NEA客户端和NEA服务器有一个受保护的会话来交换消息。这允许协议过渡到PT-TLS协商阶段。
Once a TLS session has been established between a Posture Transport Client and Posture Transport Server, the PT-TLS Initiator sends a Version Request message indicating its supported PT-TLS protocol version range. Next, the PT-TLS Responder sends a Version Response message, which selects a protocol version from within the range offered. The PT-TLS Responder SHOULD select the preferred version offered if supported; otherwise, the highest version that the responder is able to support from the received Version Request message will be used. If the PT-TLS Responder is unable or unwilling to support any of the versions included in the Version Request message, the responder SHOULD send a Version Not Supported error message.
一旦姿态传输客户端和姿态传输服务器之间建立了TLS会话，PT-TLS启动器将发送一条版本请求消息，指示其支持的PT-TLS协议版本范围。接下来，PT-TLS响应程序发送版本响应消息，该消息从提供的范围内选择协议版本。PT-TLS响应者应选择提供的首选版本（如果支持）；否则，将使用响应程序能够从收到的版本请求消息中支持的最高版本。如果PT-TLS响应程序无法或不愿意支持版本请求消息中包含的任何版本，则响应程序应发送版本不支持错误消息。
If no client-side authentication occurred during the TLS Setup phase, the Posture Transport Server can authenticate the client using PT-TLS client authentication messages as described in Section 3.8. The NEA Server initiates the client authentication and indicates when the authentication is complete.
如果在TLS设置阶段未发生客户端身份验证，则姿态传输服务器可以使用PT-TLS客户端身份验证消息对客户端进行身份验证，如第3.8节所述。NEA服务器启动客户端身份验证，并指示身份验证何时完成。
When the NEA Client receives the Simple Authentication and Security Layer (SASL) [RFC4422] Mechanisms list, the NEA Client responds with a SASL Mechanism Selection TLV indicating the method of authentication to be used. Upon selecting an appropriate SASL
当NEA客户端接收到简单身份验证和安全层（SASL）[RFC4422]机制列表时，NEA客户端用指示要使用的身份验证方法的SASL机制选择TLV进行响应。选择合适的SASL后
mechanism, the NEA Client and Server exchange SASL-mechanism-specific messages in order to authenticate the NEA Client. When the client authentication successfully completes and no additional authentications are required (as indicated by the NEA Server sending an empty SASL Mechanisms list), the PT-TLS session transitions into the Data Transport phase, where it will remain for the duration of the session. Note that the NEA Server could choose to not authenticate the client (indicated by only sending an empty SASL Mechanisms list) or to continue performing a posture assessment even if the authentication did not complete successfully.
机制，NEA客户端和服务器交换特定于SASL机制的消息，以便对NEA客户端进行身份验证。当客户端身份验证成功完成且无需额外身份验证时（如NEA服务器发送空SASL机制列表所示），PT-TLS会话将过渡到数据传输阶段，在该阶段，它将在会话期间保持不变。请注意，NEA服务器可以选择不验证客户端（仅发送空的SASL机制列表表示），或者继续执行姿势评估，即使验证未成功完成。
Once a PT-TLS session is available to carry NEA assessments, PT-TLS allows either side of the connection to send the first PB-TNC batch. The PB-TNC standard prescribes whether the Posture Broker Client or Posture Broker Server starts the assessment. The assessment initiator first envelopes the PB-TNC batch in a PT-TLS message, then assigns a message identifier to the message and finally transmits it over the session. The assessment responder validates the PT-TLS message and delivers the encapsulated PB-TNC batch to its upstream component (Posture Broker Client or Server).
一旦PT-TLS会话可用于进行NEA评估，PT-TLS允许连接的任何一方发送第一批PB-TNC。PB-TNC标准规定了姿态代理客户端或姿态代理服务器是否启动评估。评估发起人首先将PB-TNC批封装在PT-TLS消息中，然后将消息标识符分配给消息，最后通过会话进行传输。评估响应者验证PT-TLS消息，并将封装的PB-TNC批传递给其上游组件（姿态代理客户端或服务器）。
Most PT-TLS messages contain PB-TNC batches that house PA-TNC requests for posture information or a response containing the requested posture information. The Posture Transport Client and Posture Transport Server may also exchange messages between them, such as a PT-TLS Error message indicating that a problem occurred processing a message. During an assessment, the Posture Transport Client and Server merely encapsulate and exchange the PB-TNC batches and are unaware of the state of the assessment.
大多数PT-TLS消息包含PB-TNC批，其中包含PA-TNC对姿势信息的请求或包含所请求姿势信息的响应。姿态传输客户端和姿态传输服务器还可以在它们之间交换消息，例如指示处理消息时出现问题的PT-TLS错误消息。在评估过程中，姿态传输客户端和服务器仅封装和交换PB-TNC批，不知道评估的状态。
The PT-TLS protocol allows either party to send a PT-TLS message at any time, reflecting the full-duplex nature of the underlying TLS session. For example, an assessment initiator may send several PT-TLS messages prior to receiving any responses from the assessment responder. All implementations of PT-TLS MUST support full-duplex PT-TLS message exchange. However, some higher-layer NEA protocols (e.g., PB-TNC) may not be able to fully make use of the full-duplex message exchange.
PT-TLS协议允许任何一方随时发送PT-TLS消息，以反映底层TLS会话的全双工性质。例如，评估发起人可以在从评估响应者接收任何响应之前发送多个PT-TLS消息。PT-TLS的所有实现必须支持全双工PT-TLS消息交换。然而，一些更高层的NEA协议（例如PB-TNC）可能无法充分利用全双工消息交换。
In order to ensure that strong security is always available for deployers and to improve interoperability, this section discusses some requirements on the underlying TLS transport used by PT-TLS. Whenever TLS is used by this specification, the appropriate version (or versions) of TLS will vary over time, based on the widespread
为了确保部署人员始终具有强大的安全性并提高互操作性，本节讨论了PT-TLS使用的底层TLS传输的一些要求。每当本规范使用TLS时，TLS的适当版本（或多个版本）将随着时间的推移而变化，这取决于广泛的应用
deployment and known security vulnerabilities. At the time of this writing, TLS version 1.2 [RFC5246] is the most recent version, but it has a very limited deployment base and might not be readily available for implementation. TLS version 1.0 [RFC2246] and version 1.1 [RFC4346] are the most widely deployed versions and will provide the broadest interoperability. Implementations of PT-TLS SHOULD support use of TLS 1.2.
部署和已知的安全漏洞。在撰写本文时，TLS版本1.2[RFC5246]是最新的版本，但它的部署基础非常有限，可能无法立即实现。TLS版本1.0[RFC2246]和版本1.1[RFC4346]是部署最广泛的版本，将提供最广泛的互操作性。PT-TLS的实现应支持TLS 1.2的使用。
For each TLS version supported, implementations of the PT-TLS protocol MUST at least support the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite. This cipher suite requires the server to provide a certificate that can be used during the key exchange. Implementations SHOULD NOT include support for cipher suites that do not minimally offer PT-TLS Responder (typically Posture Transport Server) authentication, such as the anonymous Diffie-Hellman cipher suites (e.g., TLS_DH_anon_WITH_AES_128_CBC_SHA). Implementations MUST support RFC 5746 [RFC5746]. Implementations MAY allow renegotiation to provide confidentiality for the client certificate. If renegotiation is allowed, implementations need to select the appropriate handshake messages as described in RFC 5929 for the tls-unique value.
对于支持的每个TLS版本，PT-TLS协议的实现必须至少支持TLS_RSA_和_AES_128_CBC_SHA密码套件。此密码套件要求服务器提供可在密钥交换期间使用的证书。实施不应包括对密码套件的支持，这些密码套件不至少提供PT-TLS响应程序（通常是姿态传输服务器）身份验证，例如匿名Diffie-Hellman密码套件（例如，TLS_DH_anon_WITH_AES_128_CBC_SHA）。实现必须支持RFC 5746[RFC5746]。实现可能允许重新协商以为客户端证书提供机密性。如果允许重新协商，则实现需要为tls唯一值选择RFC 5929中所述的适当握手消息。
This section describes the format and semantics of the PT-TLS message. Every message sent over a PT-TLS session MUST start with the PT-TLS header described in this section.
本节描述PT-TLS消息的格式和语义。通过PT-TLS会话发送的每条消息必须以本节中描述的PT-TLS头开始。
The PT-TLS header format is as follows:
PT-TLS标头格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Message Type Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Value (e.g., PB-TNC Batch) . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Message Type Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Value (e.g., PB-TNC Batch) . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
含蓄的
Reserved for future use. This field MUST be set to 0 on transmission and ignored upon reception.
保留供将来使用。此字段在传输时必须设置为0，在接收时忽略。
Message Type Vendor ID
消息类型供应商ID
This field indicates the owner of the namespace associated with the message type. This is accomplished by specifying the 24-bit Structure of Management Information (SMI) Private Enterprise Number [PEN] (Vendor ID) of the party who owns the message type namespace. Consistent with PA-TNC and PB-TNC, we depend on the PEN fitting in 24 bits, so if IANA were to register a wider PEN, then that PEN could not be used with NEA. IETF namespace PT-TLS Message Types MUST use zero (0) in this field. For more information about the intended use of NEA namespace identifiers, see the PA-TNC specification (RFC 5792), Sections 2.1 and 2.2.
此字段指示与消息类型关联的命名空间的所有者。这是通过指定拥有消息类型命名空间的一方的管理信息（SMI）私有企业编号[PEN]（供应商ID）的24位结构来实现的。与PA-TNC和PB-TNC一致，我们依赖24位的笔配件，因此如果IANA要注册更宽的笔，那么该笔不能与NEA一起使用。IETF命名空间PT-TLS消息类型在此字段中必须使用零（0）。有关NEA名称空间标识符预期用途的更多信息，请参阅PA-TNC规范（RFC 5792），第2.1和2.2节。
The PT-TLS Message Type Vendor ID 0xffffff is reserved. Posture Transport Clients and Servers MUST NOT send PT-TLS messages in which the PT-TLS Message Type Vendor ID has this reserved value (0xffffff). If a Posture Transport Client or Posture Transport Server receives a message containing this reserved value (0xffffff) in the PT-TLS Message Type Vendor ID, the recipient SHOULD respond with an Invalid Parameter error code in a PT-TLS Error message.
保留PT-TLS消息类型供应商ID 0xffffff。姿态传输客户端和服务器不得发送PT-TLS消息类型供应商ID具有此保留值（0xffffff）的PT-TLS消息。如果姿态传输客户端或姿态传输服务器收到PT-TLS消息类型供应商ID中包含此保留值（0xffffff）的消息，则收件人应在PT-TLS错误消息中使用无效参数错误代码进行响应。
Message Type
消息类型
This field defines the type of the PT-TLS message within the scope of the specified Message Type Vendor ID that is included in the Message Value field. The specific IETF-defined values allowable in this field when the Message Type Vendor ID is the IETF SMI Private Enterprise Number value (0) are defined in Section 3.6. Recipients of a message containing a Message Type Vendor ID and a message type that is unrecognized SHOULD respond with a Type Not Supported error code in a PT-TLS Error message.
此字段在消息值字段中包含的指定消息类型供应商ID的范围内定义PT-TLS消息的类型。当消息类型供应商ID为IETF SMI私有企业编号值（0）时，此字段中允许的特定IETF定义值在第3.6节中定义。包含消息类型供应商ID和无法识别的消息类型的消息的收件人应在PT-TLS错误消息中使用类型不受支持的错误代码进行响应。
Posture Transport Clients and Posture Transport Servers MUST NOT require support for particular vendor-defined PT-TLS Message Types in order to interoperate with other PT-TLS compliant implementations (although implementations MAY permit administrators to configure them to require support for specific vendor-defined PT-TLS Message Types).
姿态传输客户端和姿态传输服务器不得要求支持特定供应商定义的PT-TLS消息类型，以便与其他符合PT-TLS的实施进行互操作（尽管实施可能允许管理员将其配置为需要支持特定供应商定义的PT-TLS消息类型）。
If the PT-TLS Message Type Vendor ID field has the value zero (0), then the PT-TLS Message Type field contains an IETF namespace PT-TLS Message Type, as listed in the IANA registry. IANA maintains a registry of PT-TLS Message Types. Entries in this registry are added following the IANA Specification Required policy, following the guidelines in Section 6.1. Section 3.6 of this specification defines the initial set of IETF-defined PT-TLS Message Types.
如果PT-TLS消息类型供应商ID字段的值为零（0），则PT-TLS消息类型字段包含IETF命名空间PT-TLS消息类型，如IANA注册表中所列。IANA维护PT-TLS消息类型的注册表。此注册表中的条目是按照IANA规范要求的政策以及第6.1节中的指南添加的。本规范第3.6节定义了IETF定义的PT-TLS消息类型的初始集。
The PT-TLS Message Type 0xffffffff is reserved. Posture Transport Clients and Posture Transport Servers MUST NOT send PT-TLS messages in which the PT-TLS Message Type has this reserved value (0xffffffff). If a Posture Transport Client or Posture Transport Server receives a message in which the PT-TLS Message Type has this reserved value (0xffffffff), it SHOULD respond with an Invalid Parameter error code in a PT-TLS Error message.
保留PT-TLS消息类型0xFFFFFF。姿态传输客户端和姿态传输服务器不得发送PT-TLS消息类型具有此保留值（0xFFFFFF）的PT-TLS消息。如果姿态传输客户端或姿态传输服务器接收到PT-TLS消息类型具有此保留值（0xFFFFFF）的消息，则应在PT-TLS错误消息中使用无效参数错误代码进行响应。
Message Length
消息长度
This field contains the length in octets of the entire PT-TLS message (including the entire header). Therefore, this value MUST always be at least 16. Any Posture Transport Client or Posture Transport Server that receives a message with a PT-TLS Message Length field whose value is less than 16 SHOULD respond with an Invalid Parameter PT-TLS Error Code. Similarly, if a Posture Transport Client or Posture Transport Server receives a PT-TLS message for a Message Type that has a known Message Length and the Message Length indicates a different value (greater or less than the expected value), the recipient SHOULD respond with an Invalid Parameter PT-TLS Error Code.
此字段包含整个PT-TLS消息（包括整个标头）的长度（以八位字节为单位）。因此，该值必须始终至少为16。接收带有PT-TLS消息长度字段（其值小于16）的消息的任何姿态传输客户端或姿态传输服务器应使用无效参数PT-TLS错误代码进行响应。类似地，如果姿态传输客户端或姿态传输服务器接收到具有已知消息长度的消息类型的PT-TLS消息，并且消息长度指示不同的值（大于或小于预期值），则接收方应使用无效参数PT-TLS错误代码进行响应。
Message Identifier
消息标识符
This field contains a value that uniquely identifies the PT-TLS message on a per message sender (Posture Transport Client or Server) basis. This value is copied into the body of the PT-TLS Error message so the recipient can determine which message caused the error.
此字段包含一个值，该值在每个消息发送者（姿态传输客户端或服务器）的基础上唯一标识PT-TLS消息。此值将复制到PT-TLS错误消息的正文中，以便收件人可以确定是哪条消息导致了错误。
The Message Identifier MUST be a monotonically increasing counter starting at zero indicating the number of the messages the sender has transmitted over the TLS session. It is possible that a busy or long-lived session might exceed 2^32-1 messages sent, so the message sender MUST roll over to zero upon reaching the 2^32nd message, thus restarting the increasing counter. During a rollover, it is feasible that the message recipient could be confused if it keeps track of every previously received Message Identifier, so recipients MUST be able to handle rollover situations without generating errors.
消息标识符必须是一个单调递增的计数器，从零开始，指示发送方通过TLS会话传输的消息数。繁忙或长期会话可能会超过发送的2^32-1条消息，因此消息发送方在到达第2 ^32条消息时必须将其回滚到零，从而重新启动递增计数器。在滚动期间，如果消息接收者跟踪以前接收到的每个消息标识符，则消息接收者可能会感到困惑，因此接收者必须能够在不产生错误的情况下处理滚动情况。
Message Value
消息值
The contents of this field vary depending on the particular Message Type Vendor ID and Message Type given in the PT-TLS header for this PT-TLS message. This field most frequently contains a PB-TNC batch. The contents of this field for each of the initial IETF namespace PT-TLS Message Types are defined in this specification.
此字段的内容因PT-TLS消息的PT-TLS标头中给定的特定消息类型供应商ID和消息类型而异。此字段通常包含PB-TNC批次。本规范中定义了每个初始IETF名称空间PT-TLS消息类型的此字段内容。
This section defines the NEA standard PT-TLS Message Types used to carry PT-TLS messages and PB-TNC batches between the Posture Transport Client and Posture Transport Server.
本节定义了用于在姿态传输客户端和姿态传输服务器之间传输PT-TLS消息和PB-TNC批的NEA标准PT-TLS消息类型。
The following table summarizes the initial set of IETF-defined message type values, which are used with the PT-TLS Message Type Vendor ID field set to the IETF SMI PEN (0). Note that the IANA administers a PEN value of 0 on behalf of the IETF. These descriptions only apply to the IETF namespace.
下表总结了IETF定义的消息类型值的初始集，这些值与设置为IETF SMI笔（0）的PT-TLS消息类型供应商ID字段一起使用。请注意，IANA代表IETF管理笔值0。这些描述仅适用于IETF名称空间。
Value (Name) Definition
---------------------------- ---------------------------------------
0 (Experimental) Reserved for experimental use. This
type will not offer interoperability
but allows for experimentation. This
message type MUST only be sent when the
NEA Client and NEA Server are in the
Data Transport phase and only on a
restricted, experimental network.
Compliant implementations MUST send an
Invalid Message error code in a PT-TLS
Error message if an Experimental
message is received.
Value (Name) Definition
---------------------------- ---------------------------------------
0 (Experimental) Reserved for experimental use. This
type will not offer interoperability
but allows for experimentation. This
message type MUST only be sent when the
NEA Client and NEA Server are in the
Data Transport phase and only on a
restricted, experimental network.
Compliant implementations MUST send an
Invalid Message error code in a PT-TLS
Error message if an Experimental
message is received.
1 (Version Request) Version negotiation request including the range of versions supported by the sender. This message type MUST only be sent by the TLS session initiator as the first PT-TLS message in the PT-TLS Negotiation phase. Recipients MUST send an Invalid Message error code in a PT-TLS Error message if a Version Request is received at another time.
1（版本请求）版本协商请求，包括发送方支持的版本范围。此消息类型只能由TLS会话启动器作为PT-TLS协商阶段的第一条PT-TLS消息发送。如果在其他时间收到版本请求，则收件人必须在PT-TLS错误消息中发送无效的消息错误代码。
2 (Version Response) PT-TLS protocol version selected by the responder. This message type MUST only be sent by the PT-TLS Responder as the second message in the PT-TLS Negotiation phase. Recipients MUST send an Invalid Message error code in a PT-TLS Error message if a Version Response is received at another time.
2（版本响应）响应者选择的PT-TLS协议版本。此消息类型只能由PT-TLS响应程序作为PT-TLS协商阶段的第二条消息发送。如果在其他时间收到版本响应，则收件人必须在PT-TLS错误消息中发送无效消息错误代码。
3 (SASL Mechanisms) Sent by the NEA Server to indicate what SASL mechanisms it is willing to use for authentication on this session. This message type MUST only be sent by the NEA Server in the PT-TLS Negotiation phase. The NEA Client MUST send an Invalid Message error code in a PT-TLS Error message if a SASL Mechanisms message is received at another time.
3（SASL机制）由NEA服务器发送，以指示它愿意在此会话上使用哪些SASL机制进行身份验证。此消息类型只能在PT-TLS协商阶段由NEA服务器发送。如果在其他时间收到SASL机制消息，NEA客户端必须在PT-TLS错误消息中发送无效消息错误代码。
4 (SASL Mechanism Selection) Sent by the NEA Client to select a SASL mechanism from the list offered by the NEA Server. This message type MUST only be sent by the NEA Client in the PT-TLS Negotiation phase. The NEA Server MUST send an Invalid Message error code in a PT-TLS Error message if a SASL Mechanism Selection is received after the PT-TLS Negotiation phase. Once a SASL mechanism has been selected, it may not change until the mechanism completes either successfully or as a failure.
4（SASL机制选择）由NEA客户端发送，用于从NEA服务器提供的列表中选择SASL机制。此消息类型只能由NEA客户端在PT-TLS协商阶段发送。如果在PT-TLS协商阶段后收到SASL机制选择，则NEA服务器必须在PT-TLS错误消息中发送无效消息错误代码。一旦选择了SASL机制，在该机制成功或失败完成之前，它可能不会更改。
5 (SASL Authentication Data) Opaque octets exchanged between the NEA Client and NEA Server's SASL mechanisms to perform the client authentication. This message type MUST only be sent during the PT-TLS Negotiation phase. Recipients MUST send an Invalid Message error code in a PT-TLS Error message if a SASL Authentication Data message is received after the PT-TLS Negotiation phase.
5（SASL身份验证数据）NEA客户端和NEA服务器的SASL机制之间交换的不透明八位字节，用于执行客户端身份验证。此消息类型只能在PT-TLS协商阶段发送。如果在PT-TLS协商阶段之后收到SASL身份验证数据消息，则收件人必须在PT-TLS错误消息中发送无效消息错误代码。
6 (SASL Result) Indicates the result code of the SASL mechanism authentication as described in Section 3.8.10. This message type MUST only be sent by the NEA Server when the NEA Client and NEA Server are in the PT-TLS Negotiation phase. The NEA Client MUST send an Invalid Message error code in a PT-TLS Error message if a SASL Result is received after the PT-TLS Negotiation phase.
6（SASL结果）表示第3.8.10节所述的SASL机制认证的结果代码。只有当NEA客户端和NEA服务器处于PT-TLS协商阶段时，NEA服务器才能发送此消息类型。如果在PT-TLS协商阶段后收到SASL结果，NEA客户端必须在PT-TLS错误消息中发送无效消息错误代码。
7 (PB-TNC Batch) Contains a PB-TNC batch. For more information on PB-TNC batches, see RFC 5793 (PB-TNC) Section 4. This message type MUST only be sent when the NEA Client and NEA Server are in the PT-TLS Data Transport phase. Recipients SHOULD send an Invalid Message error code in a PT-TLS Error message if a PB-TNC Batch is received outside of the Data Transport phase.
7（PB-TNC批次）包含一个PB-TNC批次。有关PB-TNC批次的更多信息，请参阅RFC 5793（PB-TNC）第4节。仅当NEA客户端和NEA服务器处于PT-TLS数据传输阶段时，才能发送此消息类型。如果在数据传输阶段之外收到PB-TNC批处理，则收件人应在PT-TLS错误消息中发送无效消息错误代码。
8 (PT-TLS Error) PT-TLS Error message as described in Section 3.9. This message type may be used during any PT-TLS phase.
8（PT-TLS错误）PT-TLS错误消息，如第3.9节所述。此消息类型可在任何PT-TLS阶段使用。
9-4294967294 (Unassigned) These values are for future allocation following guidelines defined in the IANA Considerations section (see Section 6.1). Recipients of unsupported messages in the IETF namespace using a message type of 9 to 4294967294 MUST respond with a Type Not Supported PT-TLS Error Code in a PT-TLS Error message.
9-4294967294（未分配）这些值是根据IANA注意事项一节（见第6.1节）中定义的指南用于未来分配的。IETF命名空间中使用9到4294967294消息类型的不受支持消息的收件人必须在PT-TLS错误消息中使用类型不受支持的PT-TLS错误代码进行响应。
4294967295 Reserved
4294967295保留
This section describes the message format and semantics for the PT-TLS protocol version negotiation. This exchange is used by the PT-TLS Initiator to trigger a version negotiation at the start of an assessment. The PT-TLS Initiator MUST send a Version Request message as its first PT-TLS message and MUST NOT send any other PT-TLS messages on this connection until it receives a Version Response message or an Error message. The PT-TLS Responder MUST complete the version negotiation (or cause an error) prior to sending or accepting
本节描述PT-TLS协议版本协商的消息格式和语义。PT-TLS启动器使用此交换在评估开始时触发版本协商。PT-TLS启动器必须发送版本请求消息作为其第一条PT-TLS消息，并且在收到版本响应消息或错误消息之前，不得在此连接上发送任何其他PT-TLS消息。PT-TLS响应者必须在发送或接受之前完成版本协商（或导致错误）
reception of any additional messages. After the successful completion of the version negotiation, both the Posture Transport Client and Posture Transport Server MUST only send messages compliant with the negotiated protocol version. Subsequent assessments on the same session MUST use the negotiated version number and therefore MUST NOT send additional version negotiation messages.
接收任何附加信息。成功完成版本协商后，姿态传输客户端和姿态传输服务器必须仅发送符合协商协议版本的消息。同一会话上的后续评估必须使用协商版本号，因此不得发送其他版本协商消息。
This message is sent by a PT-TLS Initiator as the first PT-TLS message in a PT-TLS session. This message discloses the sender's supported versions of the PT-TLS protocol. To ensure compatibility, this message MUST always be sent using version 1 of the PT-TLS protocol. Recipients of this message MUST respond with a Version Response or with a PT-TLS Error message (Version Not Supported or Invalid Message). The following diagram shows the format of the Version Request message:
此消息由PT-TLS启动器发送，作为PT-TLS会话中的第一条PT-TLS消息。此消息公开了发送方支持的PT-TLS协议版本。为确保兼容性，必须始终使用PT-TLS协议的版本1发送此消息。此邮件的收件人必须使用版本响应或PT-TLS错误消息（版本不受支持或消息无效）进行响应。下图显示了版本请求消息的格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Min Vers | Max Vers | Pref Vers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Min Vers | Max Vers | Pref Vers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
含蓄的
Reserved for future use. This field MUST be set to 0 on transmission and ignored upon reception.
保留供将来使用。此字段在传输时必须设置为0，在接收时忽略。
Min Vers
Min Vers
This field contains the minimum version of the PT-TLS protocol supported by the sender. This field MUST be set to 1 indicating support for the first version of PT-TLS. However, future versions of this specification will probably remove this requirement, so PT-TLS Responders MUST be prepared to receive other values.
此字段包含发送方支持的PT-TLS协议的最低版本。此字段必须设置为1，表示支持PT-TLS的第一个版本。然而，本规范的未来版本可能会删除此要求，因此PT-TLS响应程序必须准备好接收其他值。
Max Vers
马克斯·弗斯
This field contains the maximum version of the PT-TLS protocol supported by the sender. This field MUST be set to 1 indicating support for the first version of PT-TLS. However, future versions of this specification will probably remove this requirement, so PT-TLS Responders MUST be prepared to receive other values.
此字段包含发送方支持的PT-TLS协议的最高版本。此字段必须设置为1，表示支持PT-TLS的第一个版本。然而，本规范的未来版本可能会删除此要求，因此PT-TLS响应程序必须准备好接收其他值。
Pref Vers
优先股
This field contains the sender's preferred version of the PT-TLS protocol. This is a hint to the recipient that the sender would like this version selected if supported. The value of this field MUST fall within the range of Min Vers to Max Vers. This field MUST be set to 1 indicating support for the first version of PT-TLS. However, future versions of this specification will probably remove this requirement, so PT-TLS Responders MUST be prepared to receive other values.
此字段包含发送方首选的PT-TLS协议版本。这是对收件人的提示，提示发件人希望选择此版本（如果支持）。此字段的值必须在最小值到最大值的范围内。此字段必须设置为1，表示支持PT-TLS的第一个版本。然而，本规范的未来版本可能会删除此要求，因此PT-TLS响应程序必须准备好接收其他值。
This message is sent in response to receiving a Version Request message at the start of a new assessment session. If a recipient receives a Version Request after a successful version negotiation has occurred on the session, the recipient MUST send an Invalid Message error code in a PT-TLS Error message and have TLS close the session. This message MUST be sent using the syntax, semantics, and requirements of the protocol version specified in this message.
此消息是在新评估会话开始时收到版本请求消息时发送的。如果收件人在会话上成功进行版本协商后收到版本请求，则收件人必须在PT-TLS错误消息中发送无效消息错误代码，并让TLS关闭会话。必须使用此消息中指定的协议版本的语法、语义和要求发送此消息。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
含蓄的
Reserved for future use. This field MUST be set to 0 on transmission and ignored upon reception.
保留供将来使用。此字段在传输时必须设置为0，在接收时忽略。
Version
版本
This field contains the version selected by the sender of this message. The version selected MUST be within the Min Vers to Max Vers inclusive range sent in the Version Request message. If a PT-TLS Initiator receives a message with an invalid Version selected, the PT-TLS Initiator MUST respond with a Version Not Supported PT-TLS Error message.
此字段包含此邮件的发件人选择的版本。所选版本必须在版本请求消息中发送的最小版本到最大版本的范围内。如果PT-TLS启动器收到选择了无效版本的消息，则PT-TLS启动器必须以版本不受支持的PT-TLS错误消息进行响应。
This section includes a description of the message format and semantics necessary to perform client authentication (authentication of the NEA Client) over PT-TLS. Client authentication could be necessary if the NEA Server requires such an authentication and it was not performed during the TLS handshake. The general model used
本节包括对通过PT-TLS执行客户端身份验证（NEA客户端身份验证）所需的消息格式和语义的描述。如果NEA服务器需要这样的身份验证，并且在TLS握手期间没有执行，则可能需要客户端身份验证。使用的一般模型
for performing an authentication of the client using PT-TLS messages is to integrate the Simple Authentication and Security Layer (SASL) [RFC4422] framework. SASL provides a number of standards-based authentication mechanisms capable of authenticating the NEA Client using a variety of base technologies.
为了使用PT-TLS消息执行客户端身份验证，需要集成简单身份验证和安全层（SASL）[RFC4422]框架。SASL提供了许多基于标准的身份验证机制，能够使用各种基本技术对NEA客户端进行身份验证。
Client authentication could occur during the TLS handshake using TLS-defined authentication techniques. Because this client authentication is optional, the NEA Server's policy might require the client to be authenticated by PT-TLS before performing the assessment. Similarly, the NEA Server may require a PT-TLS authentication even if the NEA Client was authenticated during the TLS handshake (e.g., to allow a user authentication after a system-level authentication occurred during the TLS handshake). The decision of whether a SASL client authentication is to occur is left to the NEA Server's policy.
使用TLS定义的身份验证技术，客户机身份验证可能在TLS握手期间发生。由于此客户端身份验证是可选的，因此NEA服务器的策略可能要求客户端在执行评估之前由PT-TLS进行身份验证。类似地，即使在TLS握手期间对NEA客户端进行了认证，NEA服务器也可能需要PT-TLS认证（例如，在TLS握手期间发生系统级认证之后允许用户认证）。是否进行SASL客户端身份验证的决定由NEA服务器的策略决定。
As discussed in Section 3.1.1, it is possible that the NEA Server may initiate the TLS session to the NEA Client, thus causing it to fill the role of TLS client during the TLS handshake. Because the NEA Server is required to possess an X.509 certificate for those times when it is acting as the TLS server (normal case), PT-TLS requires that the NEA Server MUST use its X.509 certificate for TLS client authentication during the TLS handshake to authenticate itself even when it is acting as the TLS client. In this case, the NEA Client and NEA Server will authenticate using certificates during the TLS handshake, so the PT-TLS SASL client authentication might not be required unless NEA Server policy required an additional authentication of the NEA Client. Therefore, the normal usage for the SASL messages is when the NEA Client acted as the TLS client and did not authenticate during the TLS handshake.
如第3.1.1节所述，NEA服务器可能会启动与NEA客户端的TLS会话，从而使其在TLS握手期间担任TLS客户端的角色。由于NEA服务器在充当TLS服务器时（正常情况下）需要拥有X.509证书，因此PT-TLS要求NEA服务器在TLS握手期间必须使用其X.509证书进行TLS客户端身份验证，以对自身进行身份验证，即使在充当TLS客户端时也是如此。在这种情况下，NEA客户端和NEA服务器将在TLS握手期间使用证书进行身份验证，因此可能不需要PT-TLS SASL客户端身份验证，除非NEA服务器策略要求对NEA客户端进行额外身份验证。因此，SASL消息的正常用法是当NEA客户端充当TLS客户端并且在TLS握手期间未进行身份验证时。
Implementations compliant with the PT-TLS specification MUST implement the PT-TLS client authentication messages described in this section. These PT-TLS client authentication messages are capable of carrying a variety of SASL authentication mechanisms' exchanges. In order to ensure interoperability, all PT-TLS implementations compliant with this specification MUST at least support the PLAIN SASL mechanism [RFC4616]. Similarly, implementations MUST provide the EXTERNAL SASL mechanism if both parties are authenticated during the TLS establishment. In order to be able to take advantage of other strong, widely deployed authentication technologies such as Kerberos and support for channel bindings, implementations MAY
符合PT-TLS规范的实现必须实现本节中描述的PT-TLS客户端身份验证消息。这些PT-TLS客户端身份验证消息能够承载各种SASL身份验证机制的交换。为了确保互操作性，符合本规范的所有PT-TLS实现必须至少支持普通SASL机制[RFC4616]。类似地，如果双方在TLS建立期间都经过身份验证，则实现必须提供外部SASL机制。为了能够利用其他强大的、广泛部署的身份验证技术，如Kerberos和对通道绑定的支持，实现可能需要
include support for GS2 (the second Generic Security Service Application Program Interface (GSS-API) bridge for SASL) [RFC5801]. GS2 includes negotiable support for channel binding for use with SASL (see Section 5 of RFC 5801).
包括对GS2（用于SASL的第二个通用安全服务应用程序接口（GSS-API）桥接器）[RFC5801]的支持。GS2包括用于SASL的通道绑定的可协商支持（参见RFC 5801第5节）。
Implementations MUST also support the case where no client authentication is required.
实现还必须支持不需要客户端身份验证的情况。
Mechanism negotiation is initiated by the NEA Server sending the SASL Mechanisms TLV to the NEA Client to indicate the zero or more SASL mechanisms that the NEA Server's policy is willing to use with the NEA Client. The NEA Client selects one SASL mechanism from the list and sends a SASL Mechanism Selection TLV completing the negotiation. Subsequent challenges and responses are carried within the SASL Authentication Data TLV carrying the authentication data for the selected mechanism. The authentication outcome is communicated in a SASL Result TLV containing a status code. If additional authentications are required, the NEA Server could trigger the next authentication by sending another SASL Mechanisms TLV after sending the SASL Result TLV for the current authentication mechanism.
机制协商由NEA服务器向NEA客户端发送SASL机制TLV来启动，以指示NEA服务器的策略愿意与NEA客户端一起使用的零个或多个SASL机制。NEA客户端从列表中选择一个SASL机制，并发送一个SASL机制选择TLV以完成协商。随后的质询和响应在SASL身份验证数据TLV中进行，该TLV携带所选机制的身份验证数据。认证结果在包含状态代码的SASL结果TLV中传递。如果需要额外的身份验证，NEA服务器可以在发送当前身份验证机制的SASL结果TLV后，通过发送另一个SASL机制TLV来触发下一次身份验证。
The SASL client authentication starts when the NEA Server enters the PT-TLS Negotiation phase and its policy indicates that an authentication of the NEA Client is necessary, such as if it was not performed during the TLS handshake protocol. The NEA Server is responsible for triggering the client authentication by sending the SASL Mechanisms TLV to the NEA Client listing the set of SASL mechanisms the server is willing to use based upon its policy.
当NEA服务器进入PT-TLS协商阶段且其策略指示需要对NEA客户端进行身份验证时（例如，如果在TLS握手协议期间未执行身份验证），SASL客户端身份验证开始。NEA服务器负责通过向NEA客户端发送SASL机制TLV来触发客户端身份验证，列出服务器根据其策略愿意使用的SASL机制集。
The NEA Client selects a SASL mechanism from the list proposed by the NEA Server or sends a PT-TLS Invalid Message error code indicating that it is unable or unwilling to perform any of the mechanisms that were offered. If the NEA Server receives a SASL Mechanism Selection TLV that contains an unacceptable SASL mechanism, the NEA Server would respond with a SASL Mechanism Error in a PT-TLS Error TLV.
NEA客户端从NEA服务器建议的列表中选择SASL机制，或发送PT-TLS无效消息错误代码，表明其无法或不愿意执行所提供的任何机制。如果NEA服务器接收到包含不可接受SASL机制的SASL机制选择TLV，则NEA服务器将在PT-TLS错误TLV中以SASL机制错误进行响应。
In situations where the NEA Server does not require a client authentication, the NEA Server MUST send a SASL Mechanisms TLV with no mechanisms included (only the PT-TLS header) indicating that the connection should transition to the PT-TLS Data Transport phase. The same mechanism is employed to indicate that a SASL authentication already performed in this session is adequate to permit transition to the PT-TLS Data Transport phase. So the NEA Server MUST always send
在NEA服务器不需要客户端身份验证的情况下，NEA服务器必须发送不包含任何机制的SASL机制TLV（仅PT-TLS标头），指示连接应过渡到PT-TLS数据传输阶段。使用相同的机制来指示已在此会话中执行的SASL身份验证足以允许过渡到PT-TLS数据传输阶段。因此，NEA服务器必须始终发送
a SASL Mechanisms TLV with no mechanisms as the last message in the PT-TLS Negotiation phase, and the NEA Client MUST NOT transition to the PT-TLS Data Transport phase until it receives such a message.
SASL机制TLV，没有机制作为PT-TLS协商阶段的最后一条消息，NEA客户端在收到此类消息之前不得转换到PT-TLS数据传输阶段。
If the NEA Server receives a NEA assessment message before the completion of the client authentication, the NEA Server MUST send an Authentication Required PT-TLS Error message indicating to the NEA Client that an authentication exchange is required prior to entering the PT-TLS Data Transport phase.
如果NEA服务器在客户端身份验证完成之前收到NEA评估消息，则NEA服务器必须向NEA客户端发送需要身份验证的PT-TLS错误消息，指示在进入PT-TLS数据传输阶段之前需要进行身份验证交换。
The NEA Server may abort the authentication exchange by sending the SASL Result TLV with a status code of Abort. The NEA Client may abort the authentication exchange by sending a PT-TLS Error message with an Error Code of SASL Mechanism Error.
NEA服务器可以通过发送状态代码为abort的SASL结果TLV来中止身份验证交换。NEA客户端可以通过发送错误代码为SASL Mechanism Error的PT-TLS错误消息中止身份验证交换。
The service name for PT-TLS is "nea-pt-tls".
PT-TLS的服务名称为“nea PT TLS”。
The PT-TLS protocol does not make use of a SASL authorization identity string as described in RFC 4422.
PT-TLS协议不使用RFC 4422中所述的SASL授权标识字符串。
The NEA PT-TLS protocol always runs under the protection of TLS. SASL security layers are not used and thus MUST be negotiated off during SASL authentication.
NEA PT-TLS协议始终在TLS的保护下运行。不使用SASL安全层，因此必须在SASL身份验证期间协商关闭。
Only one SASL mechanism authentication may be in progress at any one time. Once a SASL mechanism completes (successfully or unsuccessfully), the NEA Server MAY trigger an additional authentication by sending a SASL Mechanisms TLV.
一次只能进行一个SASL机制身份验证。一旦SASL机制完成（成功或失败），NEA服务器可通过发送SASL机制TLV触发附加认证。
SASL channel bindings are used to bind the SASL authentication to the outer TLS tunnel to ensure that the authenticating endpoints are the same as the TLS endpoints. For SASL mechanisms that support channel bindings, the tls-unique value defined in RFC 5929 is carried by the SASL mechanism. For most mechanisms, this means including the
SASL通道绑定用于将SASL身份验证绑定到外部TLS隧道，以确保身份验证端点与TLS端点相同。对于支持通道绑定的SASL机制，RFC 5929中定义的tls唯一值由SASL机制携带。对于大多数机制，这意味着包括
tls-unique value with the appropriate prefix defined in RFC 5929 in the application data portion of the SASL Mechanism channel-binding data. If the validation of the channel binding fails, then the connection MUST be aborted.
tls唯一值，具有SASL机制通道绑定数据的应用程序数据部分中RFC 5929中定义的适当前缀。如果通道绑定验证失败，则必须中止连接。
This TLV is sent by the NEA Server to indicate the list of SASL mechanisms that it is willing and able to use to authenticate the NEA Client. Each mechanism name consists of a length followed by a name. The total length of the list is determined by the TLV Length field.
该TLV由NEA服务器发送，以指示其愿意并能够用于对NEA客户端进行身份验证的SASL机制列表。每个机制名称由一个长度后跟一个名称组成。列表的总长度由TLV长度字段确定。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd| Mech Len| Mechanism Name (1-20 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd| Mech Len| Mechanism Name (1-20 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . . . . . . . . . |
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd| Mech Len| Mechanism Name (1-20 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd| Mech Len| Mechanism Name (1-20 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . . . . . . . . . |
Rsvd (Reserved)
Rsvd（预留）
Reserved for future use. This field MUST be set to 0 on transmission and ignored upon reception.
保留供将来使用。此字段在传输时必须设置为0，在接收时忽略。
Mech Len (Mechanism Name Length)
机械透镜（机构名称长度）
The length of the Mechanism Name field in octets.
机构名称字段的长度（以八位字节为单位）。
Mechanism Name
机构名称
SASL mechanism name adhering to the rules defined in RFC 4422 with no padding.
SASL机制名称遵循RFC 4422中定义的规则，无填充。
This TLV is sent by the NEA Client in order to select a SASL mechanism for use on this session.
此TLV由NEA客户端发送，以选择用于此会话的SASL机制。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd| Mech Len| Mechanism Name (1-20 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Initial Mechanism Response |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd| Mech Len| Mechanism Name (1-20 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Initial Mechanism Response |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rsvd (Reserved)
Rsvd（预留）
Reserved for future use. This field MUST be set to 0 on transmission and ignored upon reception.
保留供将来使用。此字段在传输时必须设置为0，在接收时忽略。
Mech Len (Mechanism Name Length)
机械透镜（机构名称长度）
The length of the Mechanism Name field in octets.
机构名称字段的长度（以八位字节为单位）。
Mechanism Name
机构名称
SASL mechanism name adhering to the rules defined in RFC 4422.
遵循RFC 4422中定义的规则的SASL机制名称。
Optional Initial Mechanism Response
可选初始机制响应
Initial set of authentication information required from the NEA Client to kick-start the authentication. This data is optional and if not provided would be solicited by the NEA Server in the first SASL Authentication Data TLV request.
NEA客户端启动身份验证所需的初始身份验证信息集。该数据是可选的，如果未提供，NEA服务器将在第一个SASL认证数据TLV请求中请求该数据。
This TLV carries an opaque (to PT-TLS) blob of octets being exchanged between the NEA Client and the NEA Server. This TLV facilitates their communications without interpreting any of the bytes. The SASL Authentication Data TLV MUST NOT be sent until a SASL mechanism has been established for a session. The SASL Authentication Data TLV associated with the current authentication mechanism MUST NOT be sent after a SASL Result is sent with a Result Code of Success. Additional SASL Authentication Data TLVs would be sent if the PT-TLS Initiator and Responder desire a subsequent SASL authentication to occur but only after another SASL mechanism selection exchange occurs.
该TLV携带一个不透明（至PT-TLS）的八位字节，在NEA客户端和NEA服务器之间交换。这个TLV在不解释任何字节的情况下方便了它们的通信。在为会话建立SASL机制之前，不得发送SASL身份验证数据TLV。在发送带有成功结果代码的SASL结果后，不得发送与当前身份验证机制关联的SASL身份验证数据TLV。如果PT-TLS发起方和响应方希望进行后续SASL身份验证，但仅在发生另一个SASL机制选择交换后，才会发送附加的SASL身份验证数据TLV。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SASL Mechanism Data (Variable Length) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SASL Mechanism Data (Variable Length) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SASL Mechanism Data
SASL机制数据
Opaque, variable-length set of bytes exchanged between the PT-TLS Initiator's SASL mechanism and its peer PT-TLS Responder's SASL mechanism. These bytes MUST NOT be interpreted by the PT-TLS layer.
PT-TLS启动器的SASL机制与其对等PT-TLS响应程序的SASL机制之间交换的不透明、可变长度的字节集。PT-TLS层不得解释这些字节。
This TLV is sent by the NEA Server at the conclusion of the SASL exchange to indicate the authentication result. Upon reception of a SASL Result TLV indicating an Abort, the NEA Client MUST terminate the current authentication conversation. The recipient may retry the authentication in the event of an authentication failure. Similarly, the NEA Server may request that additional SASL authentication(s) be performed after the completion of a SASL mechanism by sending another SASL Mechanisms TLV including any mechanisms dictated by its policy.
此TLV由NEA服务器在SASL交换结束时发送，以指示身份验证结果。在接收到指示中止的SASL结果TLV后，NEA客户端必须终止当前身份验证对话。如果身份验证失败，收件人可以重试身份验证。类似地，NEA服务器可以通过发送另一个SASL机制TLV（包括其策略规定的任何机制）来请求在SASL机制完成之后执行附加SASL认证。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Optional Result Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . . . . . . . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Optional Result Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . . . . . . . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Result Code
结果代码
This field contains the result of the SASL authentication exchange.
此字段包含SASL身份验证交换的结果。
Value (Name) Definition
--------------------- -------------------------------------------
0 (Success) SASL authentication was successful, and
identity was confirmed.
Value (Name) Definition
--------------------- -------------------------------------------
0 (Success) SASL authentication was successful, and
identity was confirmed.
1 (Failure) SASL authentication failed. This might be caused by the client providing an invalid user identity and/or credential pair. Note that this is not the same as a mechanism's failure to process the authentication as reported by the Mechanism Failure code.
1（失败）SASL身份验证失败。这可能是因为客户端提供了无效的用户标识和/或凭据对。请注意，这与机制失败代码报告的机制无法处理身份验证不同。
2 (Abort) SASL authentication exchange was aborted by the sender.
2（中止）发送方中止了SASL身份验证交换。
3 (Mechanism Failure) SASL "mechanism failure" during the processing of the client's authentication (e.g., not related to the user's input). For example, this could occur if the mechanism is unable to allocate memory (e.g., malloc) that is needed to process a received SASL mechanism message.
3（机制故障）处理客户端身份验证期间的SASL“机制故障”（例如，与用户输入无关）。例如，如果机制无法分配处理接收到的SASL机制消息所需的内存（例如，malloc），则可能发生这种情况。
Optional Result Data
可选结果数据
This field contains a variable-length set of additional data for a successful result. This field MUST be zero length unless the NEA Server is returning a Result Code of Success and has more data to return. For more information on the additional data with success in SASL, see RFC 4422.
此字段包含一组可变长度的附加数据，用于获得成功的结果。此字段长度必须为零，除非NEA服务器返回成功的结果代码，并且有更多数据要返回。有关SASL中成功的附加数据的更多信息，请参阅RFC 4422。
This section describes the format and contents of the PT-TLS Error message sent by the NEA Client or NEA Server when it detects a PT-TLS-level protocol error. Each error message contains an error code indicating the error that occurred, followed by a copy of the message that caused the error.
本节描述了NEA客户端或NEA服务器检测到PT TLS级协议错误时发送的PT-TLS错误消息的格式和内容。每个错误消息都包含一个错误代码，指示发生的错误，然后是导致错误的消息的副本。
When a PT-TLS error is received, the recipient MUST NOT respond with a PT-TLS error, because this could result in an infinite loop of error messages being sent. Instead, the recipient MAY log the error, modify its behavior to avoid future errors, ignore the error, terminate the assessment, or take other action as appropriate (as long as it is consistent with the requirements of this specification).
当接收到PT-TLS错误时，收件人不得响应PT-TLS错误，因为这可能会导致发送错误消息的无限循环。相反，接收方可以记录错误、修改其行为以避免未来的错误、忽略错误、终止评估或采取其他适当的措施（只要符合本规范的要求）。
The Message Value portion of a PT-TLS Error message contains the following information:
PT-TLS错误消息的消息值部分包含以下信息：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Error Code Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Copy of Original Message (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . . . . . |
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Error Code Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Copy of Original Message (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . . . . . |
Reserved
含蓄的
Reserved for future use. This field MUST be set to 0 on transmission and ignored upon reception.
保留供将来使用。此字段在传输时必须设置为0，在接收时忽略。
Error Code Vendor ID
错误代码供应商ID
This field contains the IANA-assigned SMI Private Enterprise Number for the vendor whose Error Code namespace is being used in the message. For IETF namespace Error Code values, this field MUST be set to zero (0). For other vendor-defined Error Code namespaces, this field MUST be set to the SMI Private Enterprise Number of the vendor.
此字段包含IANA为消息中使用其错误代码命名空间的供应商分配的SMI私有企业号。对于IETF命名空间错误代码值，此字段必须设置为零（0）。对于其他供应商定义的错误代码命名空间，此字段必须设置为供应商的SMI私有企业编号。
Error Code
错误代码
This field contains the error code. This error code exists within the scope of Error Code Vendor ID in this message. Posture Transport Clients and Posture Transport Servers MUST NOT require support for particular vendor-specific PT-TLS Error Codes in order to interoperate with other PT-TLS-compliant implementations (although implementations MAY permit administrators to configure them to require support for specific PT-TLS Error Codes).
此字段包含错误代码。此错误代码存在于此消息中的错误代码供应商ID的范围内。姿态传输客户端和姿态传输服务器不得要求支持特定供应商特定的PT-TLS错误代码，以便与其他符合PT-TLS的实施进行互操作（尽管实施可能允许管理员将其配置为需要支持特定的PT-TLS错误代码）。
When the Error Code Vendor ID is set to the IETF Private Enterprise Number, the following table lists the initial supported IETF-defined numeric error codes:
当错误代码供应商ID设置为IETF私有企业编号时，下表列出了初始支持的IETF定义的数字错误代码：
Value (Name) Definition
------------------------- ---------------------------------------
0 (Reserved) Reserved value indicates that the
PT-TLS Error message SHOULD be ignored
by all recipients. This MAY be used
for debugging purposes to allow a
sender to see a copy of the message
that was received.
Value (Name) Definition
------------------------- ---------------------------------------
0 (Reserved) Reserved value indicates that the
PT-TLS Error message SHOULD be ignored
by all recipients. This MAY be used
for debugging purposes to allow a
sender to see a copy of the message
that was received.
1 (Malformed Message) PT-TLS message unrecognized or unsupported. This error code SHOULD be sent when the basic message content sanity test fails. The sender of this error code MUST consider it a fatal error and abort the assessment.
1（格式错误的消息）无法识别或不支持PT-TLS消息。当基本消息内容健全性测试失败时，应发送此错误代码。此错误代码的发送方必须将其视为致命错误并中止评估。
2 (Version Not Supported) This error SHOULD be sent when a PT-TLS Responder receives a PT-TLS Version Request message containing a range of version numbers that doesn't include any version numbers that the recipient is willing and able to support on the session. All PT-TLS messages carrying the Version Not Supported error code MUST use a version number of 1. All
2（版本不受支持）当PT-TLS响应程序收到包含一系列版本号的PT-TLS版本请求消息时，应发送此错误，这些版本号不包括收件人愿意且能够在会话中支持的任何版本号。所有带有版本不支持错误代码的PT-TLS消息必须使用版本号1。全部的
parties that receive or send PT-TLS messages MUST be able to properly process an error message that meets this description, even if they cannot process any other aspect of PT-TLS version 1. The sender and receiver of this error code MUST consider it a fatal error and close the TLS session after sending or receiving this PT-TLS message.
接收或发送PT-TLS消息的各方必须能够正确处理符合此说明的错误消息，即使它们无法处理PT-TLS版本1的任何其他方面。此错误代码的发送方和接收方必须考虑它是致命错误，并在发送或接收此PT-TLS消息后关闭TLS会话。
3 (Type Not Supported) PT-TLS Message Type unknown or not supported. When a recipient receives a PT-TLS Message Type that it does not support, it MUST send back this error, ignore the message, and proceed. For example, this could occur if the sender used a Vendor ID for the Message Type that is not supported by the recipient. This error message does not indicate that a fatal error has occurred, so the assessment is allowed to continue.
3（类型不受支持）PT-TLS消息类型未知或不受支持。当收件人收到不支持的PT-TLS消息类型时，必须发回此错误，忽略该消息，然后继续。例如，如果发件人对收件人不支持的邮件类型使用供应商ID，则可能会发生这种情况。此错误消息并不表示发生了致命错误，因此允许继续评估。
4 (Invalid Message) PT-TLS message received was invalid based on the protocol state. For example, this error would be sent if a recipient receives a message associated with the PT-TLS Negotiation Phase (such as Version messages) after the protocol has reached the PT-TLS Data Transport Phase. The sender and receiver of this error code MUST consider it a fatal error and close the TLS session after sending or receiving this PT-TLS message.
4（无效消息）根据协议状态，收到的PT-TLS消息无效。例如，如果收件人在协议到达PT-TLS数据传输阶段后收到与PT-TLS协商阶段相关的消息（例如版本消息），则会发送此错误。此错误代码的发送方和接收方必须考虑它是致命错误，并在发送或接收此PT-TLS消息后关闭TLS会话。
5 (SASL Mechanism Error) A fatal error occurred while trying to perform the client authentication. For example, the NEA Client is unable to support any of the offered SASL mechanisms. The sender and receiver of this error code MUST consider it a fatal error and close the TLS session after sending or receiving this PT-TLS message.
5（SASL机制错误）尝试执行客户端身份验证时发生致命错误。例如，NEA客户端无法支持任何提供的SASL机制。此错误代码的发送方和接收方必须考虑它是致命错误，并在发送或接收此PT-TLS消息后关闭TLS会话。
6 (Invalid Parameter) The PT-TLS Error message sender has received a message with an invalid or unsupported value in the PT-TLS header. This could occur if the NEA Client receives a PT-TLS message from the NEA Server with a Message Length of zero (see Section 3.5 for details). The sender and receiver of this error code MUST consider it a fatal error and close the TLS session after sending or receiving this PT-TLS message.
6（无效参数）PT-TLS错误消息发送方已收到PT-TLS标头中包含无效或不支持值的消息。如果NEA客户端从NEA服务器接收到消息长度为零的PT-TLS消息，则可能发生这种情况（有关详细信息，请参阅第3.5节）。此错误代码的发送方和接收方必须考虑它是致命错误，并在发送或接收此PT-TLS消息后关闭TLS会话。
Copy of Original Message
原始信息的副本
This variable-length value MUST contain a copy (up to 1024 bytes) of the original PT-TLS message that caused the error. If the original message is longer than 1024 bytes, only the initial 1024 bytes will be included in this field. This field is included so the error recipient can determine which message sent caused the error. In particular, the recipient can use the Message Identifier field from the Copy of Original Message data to determine which message caused the error.
此可变长度值必须包含导致错误的原始PT-TLS消息的副本（最多1024字节）。如果原始消息长度超过1024字节，则此字段中仅包含初始1024字节。包含此字段，以便错误收件人可以确定发送的是哪封邮件导致了错误。特别是，收件人可以使用原始消息数据副本中的消息标识符字段来确定是哪条消息导致了错误。
This section discusses the major threats potentially faced by each binding of the PT protocol and countermeasures provided by the PT-TLS protocol.
本节讨论PT协议的每个绑定可能面临的主要威胁以及PT-TLS协议提供的对策。
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-TLS protocol. Implementations or deployments where these trust relationships are not present would need to provide additional countermeasures to ensure the proper operation and security of PT-TLS (which relies upon these relationships to be trustworthy). The following subsections discuss the trust properties associated with each portion of the NEA reference model directly involved with the processing of the PT-TLS protocol.
为了了解哪里需要安全对策，本节首先讨论NEA体系结构在哪里设想PT-TLS协议处理元素之间的一些信任关系。不存在这些信任关系的实施或部署将需要提供额外的对策，以确保PT-TLS的正确操作和安全性（依赖于这些关系是可信的）。以下小节讨论与PT-TLS协议处理直接相关的NEA参考模型各部分相关的信任属性。
The Posture Transport Client is trusted by the Posture Broker Client 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 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 在网络上传输从Positure Broker客户端传递的任何PB-TNC批
o Deliver properly security protected messages received from the network that are destined for the Posture Broker Client
o 传递从网络接收到的、目的地为Positure Broker客户端的、受到适当安全保护的消息
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 only to the PB-TNC layer within the NEA Client
o 仅向NEA客户端内的PB-TNC层公开姿态传输服务器的身份验证
o Verify the security protections placed upon messages received from the network to ensure that the messages are authentic and protected from attacks on the network
o 验证对从网络接收到的消息所采取的安全保护措施，以确保消息是真实的，并受到网络攻击的保护
o Provide a secure, reliable, "in-order delivery", full-duplex transport for the Posture Broker Client's messages
o 为Positure Broker客户端的消息提供安全、可靠的“按订单交付”全双工传输
The Posture Transport Client is trusted by the Posture Transport Server to:
姿态传输服务器信任姿态传输客户端：
o Not send malicious traffic intending to harm (e.g., denial of service) the Posture Transport Server
o 不发送恶意通信以损害（例如，拒绝服务）传输服务器
o Not send malformed messages (e.g., messages lacking a PT-TLS header)
o 不发送格式错误的消息（例如，缺少PT-TLS标头的消息）
o Not send invalid or incorrect responses to messages (e.g., errors when no error is warranted)
o 不向消息发送无效或不正确的响应（例如，无错误时的错误）
o Not ignore or drop messages when such an action would cause issues for the protocol processing (e.g., dropping PT-TLS SASL Authentication Data messages)
o 当此类操作会导致协议处理问题时，不得忽略或删除消息（例如，删除PT-TLS SASL身份验证数据消息）
o Verify the security protections placed upon messages received from the network to ensure that the messages are authentic and protected from attacks on the network
o 验证对从网络接收到的消息所采取的安全保护措施，以确保消息是真实的，并受到网络攻击的保护
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 在网络上传输从Protation Broker服务器传递的任何PB-TNC批
o Deliver properly security protected messages received from the network that are destined for the Posture Broker Server
o 传递从网络接收并发送到Positure Broker服务器的具有适当安全保护的消息
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 only to the PB-TNC layer within the NEA Server
o 仅向NEA服务器内的PB-TNC层公开姿态传输客户端的身份验证
o Verify the security protections placed upon messages received from the network to ensure that the messages are authentic and protected from attacks on the network
o 验证对从网络接收到的消息所采取的安全保护措施，以确保消息是真实的，并受到网络攻击的保护
o Provide a secure, reliable, "in-order delivery", full-duplex transport for the Posture Broker Server's messages
o 为Postition Broker服务器的消息提供安全、可靠的“按顺序传递”全双工传输
The Posture Transport Server is trusted by the Posture Transport Client to:
姿态传输客户端信任姿态传输服务器：
o Not send malicious traffic intending to harm (e.g., denial of service) the Posture Transport Client
o 不发送意图伤害（例如拒绝服务）传输客户端的恶意通信
o Not send malformed messages (e.g., messages lacking a PT-TLS header)
o 不发送格式错误的消息（例如，缺少PT-TLS标头的消息）
o Not send invalid or incorrect responses to messages (e.g., errors when no error is warranted)
o 不向消息发送无效或不正确的响应（例如，无错误时的错误）
o Not ignore or drop messages when such an action would cause issues for the protocol processing (e.g., dropping PT-TLS SASL Result messages)
o 当此类操作会导致协议处理问题时，不得忽略或删除消息（例如，删除PT-TLS SASL结果消息）
o Verify the security protections placed upon messages received from the network to ensure that the messages are authentic and protected from attacks on the network
o 验证对从网络接收到的消息所采取的安全保护措施，以确保消息是真实的，并受到网络攻击的保护
Beyond the trust relationships assumed in Section 4.1, the PT-TLS protocol faces a number of potential security attacks that could require security countermeasures.
除了第4.1节中假设的信任关系之外，PT-TLS协议还面临许多可能需要安全对策的潜在安全攻击。
Generally, the PT-TLS protocol is responsible for offering strong security protections for all of the NEA protocols, so any threats to its ability to protect NEA protocol messages could be very damaging to deployments. 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.
一般来说，PT-TLS协议负责为所有NEA协议提供强大的安全保护，因此对其保护NEA协议消息的能力的任何威胁都可能对部署造成极大损害。消息传递到姿态代理客户端或姿态代理服务器后，将信任姿态代理正确、安全地处理消息。
When PT-TLS messages are sent over unprotected network links or spanning 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 the adversary. Messages observed by eavesdroppers could contain information that exposes potential weaknesses in the security of the endpoint, or system fingerprinting information; this information would make it easier for 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-TLS does not provide confidentiality protection, an adversary could observe the PA-TNC attributes included in the PT-TLS message and determine that the endpoint is lacking patches or that particular sub-networks have more lenient policies.
当PT-TLS消息通过不受保护的网络链路或跨越不受信任的本地软件堆栈发送时，消息的内容可能会被中间方窃取。这种盗窃行为可能会导致记录信息供对手将来使用或分析。窃听者观察到的消息可能包含暴露端点安全性潜在弱点的信息或系统指纹信息；此信息将使攻击者更容易对端点实施更有可能成功的攻击。窃听者还可能了解有关端点或网络策略的信息，这些信息单独或集体地被视为敏感信息。例如，如果PT-TLS不提供保密保护，则敌方可以观察PT-TLS消息中包含的PA-TNC属性，并确定端点缺少补丁，或者特定子网具有更宽松的策略。
In order to protect against NEA assessment message theft, the PT-TLS protocol provides strong cryptographic authentication, integrity, and confidentiality protection. Deployers are strongly encouraged to employ "best practice of the day" TLS ciphers to ensure that the information remains safe despite advances in technology and discovered cipher weaknesses. The use of bidirectional authentication of the assessment transport session ensures that only properly authenticated and authorized parties may be involved in an
为了防止NEA评估消息被盗，PT-TLS协议提供了强大的加密身份验证、完整性和机密性保护。强烈鼓励部署人员使用“当日最佳实践”TLS密码，以确保信息在技术进步和发现密码漏洞的情况下仍然安全。对评估传输会话的双向认证的使用确保只有经过适当认证和授权的各方才能参与评估
assessment dialog. The PT-TLS protocol also provides strong cryptography for all of the PB-TNC and PA-TNC protocol messages traveling over the network, allowing the message contents to be hidden from potential theft by the adversary even if the attacker is able to observe the encrypted PT-TLS session.
评估对话框。PT-TLS协议还为通过网络传输的所有PB-TNC和PA-TNC协议消息提供了强大的加密功能，即使攻击者能够观察到加密的PT-TLS会话，也可以隐藏消息内容，以防对手潜在的盗窃行为。
Attackers on the network or present within the NEA system could introduce fabricated PT-TLS messages intending to trick or create a denial of service against aspects of an assessment. For example, an adversary could attempt to insert into the message exchange fake PT-TLS Error Codes in order to disrupt communications.
网络上或NEA系统内的攻击者可能会引入伪造的PT-TLS消息，以欺骗或创建针对评估方面的拒绝服务。例如，对手可能试图在消息交换中插入伪PT-TLS错误代码，以中断通信。
The PT-TLS protocol provides 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. In particular, TLS's use of hashing algorithms provides strong integrity protections that allow for detection of any changes in the content of the message stream. Additionally, adversaries are unable to observe the PT-TLS protocol exchanges because they are encrypted by the TLS ciphers and so would have difficulty determining where to insert the falsified message, since the attacker is unable to determine where the message boundaries exist. Even if a successful message insertion did occur, the recipient would be able to detect it due to failure of the TLS cipher suite's integrity check.
PT-TLS协议为网络上的完整消息交换提供了强大的安全保护。这些安全保护可防止中介将虚假消息插入评估。特别是，TLS对哈希算法的使用提供了强大的完整性保护，允许检测消息流内容的任何更改。此外，对手无法观察PT-TLS协议交换，因为它们由TLS密码加密，因此很难确定在何处插入伪造消息，因为攻击者无法确定消息边界存在的位置。即使消息插入成功，由于TLS密码套件的完整性检查失败，收件人也能够检测到它。
This attack could allow an active attacker capable of intercepting a message to modify a PT-TLS message or transported PA-TNC attribute to a desired value to make it easier to compromise 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-TLS消息或将PA-TNC属性传输到所需值，从而更容易破坏端点。由于消息收件人无法检测接收到的消息是否包含与最初发送的消息相同的内容，主动攻击者可以秘密修改属性交换。
The PT-TLS protocol leverages the TLS protocol to provide strong authentication and integrity protections as a countermeasure to this threat. The bidirectional authentication prevents the attacker from acting as an active man-in-the-middle to the protocol that could be used to modify the message exchange. The strong integrity protection (e.g., hashing) offered by TLS allows PT-TLS message recipients to detect message alterations by other types of network-based adversaries.
PT-TLS协议利用TLS协议提供强大的身份验证和完整性保护，以此作为应对此威胁的对策。双向身份验证可防止攻击者充当协议中间的活动人，该协议可用于修改消息交换。TLS提供的强大完整性保护（如哈希）允许PT-TLS消息接收者检测其他类型网络对手的消息更改。
A variety of types of denial-of-service attacks are possible against the PT-TLS protocol if the message exchanges are 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-TLS协议可能遭受多种类型的拒绝服务攻击。我们相信姿态传输客户端和姿态传输服务器不会参与评估会话的拒绝服务，从而使威胁来自网络。
The PT-TLS protocol provides bidirectional authentication capabilities in order to prevent a man-in-the-middle on the network from becoming an undetected active proxy of PT-TLS messages. Because the PT-TLS protocol runs after the TLS handshake and thus cipher establishment/use, all of the PT-TLS messages are protected from 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.
PT-TLS协议提供双向身份验证功能，以防止网络中间的人成为PT-TLS消息的未检测到的活动代理。由于PT-TLS协议在TLS握手后运行，因此密码建立/使用，因此所有PT-TLS消息都受到保护，不受可能造成拒绝服务情况的未检测到的修改的影响。但是，对手可能会更改消息流，导致收件人拒绝每条消息，因为它无法通过完整性检查。
The PT-TLS protocol operates as an application protocol on top of TLS and thus TCP/IP protocols, so is subject to denial-of-service attacks against the TLS, TCP, and IP protocols.
PT-TLS协议作为TLS和TCP/IP协议之上的应用程序协议运行，因此会受到针对TLS、TCP和IP协议的拒绝服务攻击。
As described in Section 3.3 and in [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.3 and [RFC6813] provide a detailed description of this attack and of the countermeasures that can be employed against it.
如第3.3节和[RFC6813]所述，可以对NEA系统发起复杂的MITM攻击。攻击者通过不健康机器转发来自健康机器的PA-TNC消息，以便不健康机器可以访问网络。第3.3节和[RFC6813]详细描述了该攻击以及可针对其采取的对策。
Because lying endpoint attacks are much easier than Asokan attacks and the only known 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-TLS implementers may not know whether an EMA will be used with their implementation. Therefore, PT-TLS implementers SHOULD support the Asokan attack countermeasures described in Section 3.3 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.
由于说谎端点攻击比Asokan攻击容易得多，而且已知唯一有效的对付说谎端点攻击的对策是使用外部测量代理（EMA），因此除非使用EMA，否则不需要对付Asokan攻击的对策。然而，PT-TLS实现者可能不知道EMA是否将与其实现一起使用。因此，PT-TLS实施者应支持第3.3节中描述的Asokan攻击对策，方法是提供TLS唯一通道绑定到NEA参考模型更高层的价值：姿态代理客户端、姿态代理服务器、姿态收集器和姿态验证器。
The Asokan attack can also apply to authentication mechanisms carried within TLS. SASL mechanisms providing channel bindings use the tls-unique channel-binding data as defined in Section 3.3 to protect against the attack.
Asokan攻击也可以应用于TLS中的身份验证机制。提供通道绑定的SASL机制使用第3.3节中定义的tls唯一通道绑定数据来抵御攻击。
The TLS protocol bases its trust decision about the signer of the certificates received during the TLS authentication on using a set of trust anchor certificates. It is essential that these trust anchor certificates are integrity protected from unauthorized modification. Many common software components (e.g., browsers, operating systems, security protocols) include a set of trust anchor certificates that are relevant to their operation. The PT-TLS SHOULD use a PT-TLS-specific set of trust anchor certificates in order to limit what Certificate Authorities are authorized to issue certificates for use with NEA.
TLS协议基于使用一组信任锚证书来决定在TLS身份验证期间接收到的证书的签名者的信任。必须保护这些信任锚证书的完整性，防止未经授权的修改。许多常见的软件组件（例如浏览器、操作系统、安全协议）包括一组与其操作相关的信任锚证书。PT-TLS应使用PT-TLS特定的信任锚证书集，以限制授权的证书颁发机构颁发与NEA一起使用的证书。
The role of PT-TLS is to act as a secure transport for PB-TNC and other higher-layer protocols. As such, PT-TLS does not directly utilize personally identifiable information (PII) except when client authentication is enabled. When client authentication is being used, the NEA Client will be asked to use SASL, which may disclose a local identifier (e.g., username) associated with the endpoint and an authenticator (e.g., password) to authenticate that identity. Because the identity and authenticator are potentially privacy-sensitive information, the NEA Client MUST offer a mechanism to restrict which NEA Servers will be sent this information. Similarly, the NEA Client SHOULD provide an indication to the person being identified that a request for their identity has been made in case they choose to opt out of the authentication to remain anonymous unless no user interface is available. PT-TLS provides cryptographic peer authentication, message integrity, and data confidentiality protections to higher-layer NEA protocols that may exchange data potentially including PII. These security services can be used to protect any PII involved in an assessment from passive and active attackers on the network. Endpoints sending potentially privacy-sensitive information SHOULD ensure that the PT-TLS security protections (TLS cipher suites) negotiated for an assessment of the endpoint are adequate to avoid interception and off-line attacks of any long-term privacy-sensitive information unless other network protections are already present.
PT-TLS的作用是充当PB-TNC和其他高层协议的安全传输。因此，PT-TLS不直接利用个人识别信息（PII），除非启用了客户端身份验证。当使用客户端身份验证时，将要求NEA客户端使用SASL，SASL可能会披露与端点相关联的本地标识符（例如用户名）和身份验证者（例如密码）来验证该身份。由于身份和身份验证器是潜在的隐私敏感信息，NEA客户端必须提供一种机制来限制向哪些NEA服务器发送此信息。类似地，NEA客户端应向被识别人提供一个指示，表明在他们选择退出身份验证以保持匿名的情况下，已经对他们的身份提出了请求，除非没有可用的用户界面。PT-TLS为可能交换数据（包括PII）的高层NEA协议提供加密对等身份验证、消息完整性和数据机密性保护。这些安全服务可用于保护评估中涉及的任何PII免受网络上被动和主动攻击者的攻击。发送潜在隐私敏感信息的端点应确保为评估端点而协商的PT-TLS安全保护（TLS密码套件）足以避免拦截和离线攻击任何长期隐私敏感信息，除非已经存在其他网络保护。
Per this specification, two new IANA registries have been created and a TCP port number has been assigned. IANA has permanently reserved the early allocated TCP port number 271 for use with the PT-TLS protocol.
根据此规范，已创建两个新的IANA注册表，并已分配TCP端口号。IANA已永久保留早期分配的TCP端口号271，以便与PT-TLS协议一起使用。
This section defines the contents of two new IANA registries, PT-TLS Message Types and PT-TLS Error Codes, and explains how these registries work.
本节定义了两个新的IANA注册中心PT-TLS消息类型和PT-TLS错误代码的内容，并解释了这些注册中心的工作原理。
Each of the registries defined in this document support IETF-defined values and vendor-defined values. To explain this phenomenon, we will use the PT-TLS Message Type as an example, but the other registry works the same way.
本文档中定义的每个注册中心都支持IETF定义的值和供应商定义的值。为了解释这种现象，我们将以PT-TLS消息类型为例，但另一个注册表的工作方式相同。
Whenever a PT-TLS Message Type appears on a network, it is always accompanied by an SMI Private Enterprise Number (PEN), also known as a vendor ID. If this vendor ID is zero, the accompanying PT-TLS Message Type is an IETF namespace value listed in the IANA registry for PT-TLS Message Types, and its meaning is defined in the specification listed for that PT-TLS Message Type in that registry. If the vendor ID is not zero, the meaning of the PT-TLS Message Type is defined by the vendor identified by the vendor ID (as listed in the IANA registry for SMI PENs). The identified vendor is encouraged but not required to register with IANA some or all of the PT-TLS Message Types used with their vendor ID and publish a specification for each of these values.
每当PT-TLS消息类型出现在网络上时，它总是伴随着SMI私有企业号（PEN），也称为供应商ID。如果此供应商ID为零，则伴随的PT-TLS消息类型是IANA注册表中列出的PT-TLS消息类型的IETF命名空间值，其含义在该注册表中针对该PT-TLS消息类型列出的规范中定义。如果供应商ID不为零，则PT-TLS消息类型的含义由供应商ID标识的供应商定义（如IANA注册中心SMI PENs中所列）。鼓励已识别的供应商，但不要求其向IANA注册其供应商ID使用的部分或全部PT-TLS消息类型，并发布这些值的规范。
For each of the IANA registries defined by this specification, new values are added to the registry by following the IANA Specification Required policy [RFC5226].
对于本规范定义的每个IANA注册表，通过遵循IANA规范要求策略[RFC5226]向注册表添加新值。
This section provides guidance to designated experts so that they may make decisions using a philosophy appropriate for these registries.
本节为指定专家提供指导，以便他们可以使用适用于这些登记册的理念作出决定。
The registries defined in this document have plenty of values. In most cases, the IETF has approximately 2^32 values available for it to define, and each vendor has the same number of values for its use. Because there are so many values available, designated experts should not be terribly concerned about exhausting the set of values.
本文档中定义的注册表有很多值。在大多数情况下，IETF有大约2^32个可供定义的值，每个供应商有相同数量的值供其使用。因为有这么多可用的值，指定的专家不应该非常担心耗尽这些值。
Instead, designated experts should focus on the following requirements. All values in these IANA registries are required to be documented in a specification that is permanently and publicly available. IETF namespace values must also be useful not harmful to the Internet, and defined in a manner that is clear and likely to ensure interoperability.
相反，指定专家应关注以下要求。这些IANA注册中的所有值都需要记录在永久公开的规范中。IETF名称空间值也必须是有用的，不会对互联网有害，并以明确的方式定义，以确保互操作性。
Designated experts should encourage vendors to avoid defining similar but incompatible values and instead agree on a single IETF-reviewed approach and value. However, it is beneficial to document existing practice.
指定的专家应鼓励供应商避免定义类似但不兼容的价值观，而应就单一的IETF评审方法和价值观达成一致。然而，记录现有实践是有益的。
There are several ways to ensure that a specification is permanently and publicly available. It may be published as an RFC. Alternatively, it may be published in another manner that makes it freely available to anyone. However, in this latter case, the vendor will need to supply a copy to the IANA and authorize the IANA to archive this copy and make it freely available to all if at some point the document becomes no longer freely available to all through other channels.
有几种方法可以确保规范永久和公开可用。它可以作为RFC发布。或者，它可以以另一种方式发布，使任何人都可以免费获得。但是，在后一种情况下，供应商需要向IANA提供一份副本，并授权IANA存档该副本，并在某个时候，如果文件不再通过其他渠道免费提供给所有人，则将其免费提供给所有人。
The following two sections provide guidance to the IANA in creating and managing the new IANA registries defined by this specification.
以下两节为IANA创建和管理本规范定义的新IANA注册中心提供指导。
The name for this registry is "PT-TLS Message Types". Each entry in this registry should include a human-readable name, an SMI Private Enterprise Number, a decimal integer value between 0 and 4294967294, and a reference to the specification where the contents of this message type are defined. This specification must define the meaning of the PT-TLS Message Type and the format and semantics of the PT-TLS Message Value field that include the designated Private Enterprise Number in the PT-TLS Message Type Vendor ID field and the designated numeric value in the PT-TLS Message Type field.
此注册表的名称为“PT-TLS消息类型”。此注册表中的每个条目都应包括一个人类可读的名称、一个SMI私有企业编号、一个介于0和4294967294之间的十进制整数值，以及对定义此消息类型内容的规范的引用。本规范必须定义PT-TLS消息类型的含义以及PT-TLS消息值字段的格式和语义，包括PT-TLS消息类型供应商ID字段中指定的私有企业编号和PT-TLS消息类型字段中指定的数值。
The following entries for this registry are defined in this document. Additional entries to this registry are added by following the IANA Specification Required policy, consistent with the guidelines in Section 6.1.
本文档中定义了此注册表的以下条目。按照IANA规范要求的政策，按照第6.1节中的指南，向该注册表添加其他条目。
PEN Value Name Reference
--- -------- ------------------------ ---------
0 0 Experimental RFC 6876
0 1 Version Request RFC 6876
0 2 Version Response RFC 6876
0 3 SASL Mechanisms RFC 6876
0 4 SASL Mechanism Selection RFC 6876
0 5 SASL Authentication Data RFC 6876
0 6 SASL Result RFC 6876
0 7 PB-TNC Batch RFC 6876
0 8 PT-TLS Error RFC 6876
0 9-4294967294 Unassigned
0 4294967295 Reserved RFC 6876
PEN Value Name Reference
--- -------- ------------------------ ---------
0 0 Experimental RFC 6876
0 1 Version Request RFC 6876
0 2 Version Response RFC 6876
0 3 SASL Mechanisms RFC 6876
0 4 SASL Mechanism Selection RFC 6876
0 5 SASL Authentication Data RFC 6876
0 6 SASL Result RFC 6876
0 7 PB-TNC Batch RFC 6876
0 8 PT-TLS Error RFC 6876
0 9-4294967294 Unassigned
0 4294967295 Reserved RFC 6876
The PEN 0 (IETF) PT-TLS Message Type values between 9 and 4294967294 inclusive are allocated for future assignment by the IANA.
9和4294967294（含9和4294967294）之间的PEN 0（IETF）PT-TLS消息类型值由IANA分配给未来的分配。
The name for this registry is "PT-TLS Error Codes". Each entry in this registry should include a human-readable name, an SMI Private Enterprise Number, a decimal integer value between 0 and 4294967295, and a reference to the specification where this error code is defined. This specification must define the meaning of this error code, a PT-TLS Message Type of PT-TLS Error, the designated Private Enterprise Number in the PT-TLS Error Code Vendor ID field, and the designated numeric value in the PT-TLS Error Code field.
此注册表的名称为“PT-TLS错误代码”。此注册表中的每个条目应包括一个可读名称、一个SMI私有企业编号、一个介于0和4294967295之间的十进制整数值，以及对定义此错误代码的规范的引用。本规范必须定义此错误代码的含义、PT-TLS错误的PT-TLS消息类型、PT-TLS错误代码供应商ID字段中指定的私人企业编号以及PT-TLS错误代码字段中的指定数值。
The following entries for this registry are defined in this document. Additional entries to this registry are added following the IANA Specification Required policy, consistent with the guidelines in Section 6.1.
本文档中定义了此注册表的以下条目。根据IANA规范要求的政策，按照第6.1节中的指南，向该注册表添加其他条目。
PEN Value Name Reference
--- ------------ --------------------- ---------
0 0 Reserved RFC 6876
0 1 Malformed Message RFC 6876
0 2 Version Not Supported RFC 6876
0 3 Type Not Supported RFC 6876
0 4 Invalid Message RFC 6876
0 5 SASL Mechanism Error RFC 6876
0 6 Invalid Parameter RFC 6876
0 7-4294967295 Unassigned
PEN Value Name Reference
--- ------------ --------------------- ---------
0 0 Reserved RFC 6876
0 1 Malformed Message RFC 6876
0 2 Version Not Supported RFC 6876
0 3 Type Not Supported RFC 6876
0 4 Invalid Message RFC 6876
0 5 SASL Mechanism Error RFC 6876
0 6 Invalid Parameter RFC 6876
0 7-4294967295 Unassigned
The PEN 0 (IETF) PT-TLS Error Codes between 7 and 4294967295 inclusive are allocated for future assignment by the IANA.
7和4294967295（含7和4294967295）之间的PEN 0（IETF）PT-TLS错误代码由IANA分配给未来分配。
Thanks to the Trusted Computing Group for contributing the initial text upon which this document was based [IFT-TLS].
感谢Trusted Computing Group提供了本文档所基于的初始文本[IFT-TLS]。
The authors of this document would also like to acknowledge the following people who have contributed to or provided substantial input on the preparation of this document or predecessors to it: Syam Appala, Stuart Bailey, Lauren Giroux, Steve Hanna, Josh Howlett, Scott Kelly, Carolin Latze, Sung Lee, Lisa Lorenzin, Alexey Melnikov, Ravi Sahita, Subbu Srinivasan, Susan Thomson, and Mark Townsend.
本文件的作者还想感谢以下人士，他们对本文件或其前身的编制做出了贡献或提供了大量投入：Syam Appala、Stuart Bailey、Lauren Giroux、Steve Hanna、Josh Howlett、Scott Kelly、Carolin Latze、Sung Lee、Lisa Lorenzin、Alexey Melnikov、Ravi Sahita、，苏布·斯里尼瓦桑、苏珊·汤姆森和马克·汤森。
[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月。
[RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422]Melnikov，A.，Ed.，和K.Zeilenga，Ed.，“简单身份验证和安全层（SASL）”，RFC 4422，2006年6月。
[RFC4616] Zeilenga, K., Ed., "The PLAIN Simple Authentication and Security Layer (SASL) Mechanism", RFC 4616, August 2006.
[RFC4616]Zeilenga，K.，Ed.“简单认证和安全层（SASL）机制”，RFC4616，2006年8月。
[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月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, February 2010.
[RFC5746]Rescorla，E.，Ray，M.，Dispensa，S.，和N.Oskov，“传输层安全（TLS）重新协商指示扩展”，RFC 57462010年2月。
[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月。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施中表示和验证基于域的应用程序服务标识”，RFC 61252011年3月。
[RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, February 2012.
[RFC6520]Seggelmann，R.，Tuexen，M.和M.Williams，“传输层安全性（TLS）和数据报传输层安全性（DTLS）心跳扩展”，RFC 6520，2012年2月。
[IFT-TLS] Trusted Computing Group, "TNC IF-T: Binding to TLS", <http://www.trustedcomputinggroup.org/>, May 2009.
[IFT-TLS]可信计算组，“TNC IF-T:绑定到TLS”<http://www.trustedcomputinggroup.org/>，2009年5月。
[PEN] IANA Private Enterprise Numbers (PEN) registry, <http://www.iana.org/assignments/enterprise-numbers>.
[PEN]IANA私人企业编号（PEN）登记处<http://www.iana.org/assignments/enterprise-numbers>.
[PT-EAP] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods", Work in Progress, January 2013.
[PT-EAP]Cam Winget，N.和P.Sangster，“PT-EAP：EAP隧道方法的姿态传输（PT）协议”，正在进行的工作，2013年1月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC2246，1999年1月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[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月。
[RFC5801] Josefsson, S. and N. Williams, "Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family", RFC 5801, July 2010.
[RFC5801]Josefsson，S.和N.Williams，“在简单身份验证和安全层（SASL）中使用通用安全服务应用程序接口（GSS-API）机制：GS2机制系列”，RFC 58012010年7月。
[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月。
Authors' Addresses
作者地址
Paul Sangster Symantec Corporation 6825 Citrine Dr. Carlsbad, CA 92009
Paul Sangster Symantec Corporation 6825 Citrine Dr.Carlsbad，加利福尼亚州，92009
EMail: paul_sangster@symantec.com
EMail: paul_sangster@symantec.com
Nancy Cam-Winget Cisco Systems 80 West Tasman Drive San Jose, CA 95134 US
美国加利福尼亚州圣何塞市西塔斯曼大道80号南希·坎温吉特·思科系统公司，邮编95134
EMail: ncamwing@cisco.com
EMail: ncamwing@cisco.com
Joseph Salowey Cisco Systems 2901 Third Avenue Seattle, WA 98121 US
美国华盛顿州西雅图第三大道2901号Joseph Salowey Cisco Systems 98121
EMail: jsalowey@cisco.com
EMail: jsalowey@cisco.com