Internet Engineering Task Force (IETF) P. Sangster
Request for Comments: 5792 Symantec Corporation
Category: Standards Track K. Narayan
ISSN: 2070-1721 Cisco Systems
March 2010
Internet Engineering Task Force (IETF) P. Sangster
Request for Comments: 5792 Symantec Corporation
Category: Standards Track K. Narayan
ISSN: 2070-1721 Cisco Systems
March 2010
PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)
PA-TNC：与可信网络连接（TNC）兼容的姿态属性（PA）协议
Abstract
摘要
This document specifies PA-TNC, a Posture Attribute protocol identical to the Trusted Computing Group's IF-M 1.0 protocol. The document then evaluates PA-TNC against the requirements defined in the NEA Requirements specification.
本文档指定了PA-TNC，这是一种姿态属性协议，与可信计算组的IF-M1.0协议相同。然后，该文件根据NEA要求规范中定义的要求评估PA-TNC。
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/rfc5792.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5792.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Prerequisites ..............................................4
1.2. Message Diagram Conventions ................................4
1.3. Conventions Used in This Document ..........................4
2. Design Considerations ...........................................4
2.1. Standard Attribute Namespace for Interoperability ..........4
2.2. Vendor-Defined Namespace for Differentiation and Agility ...5
2.3. Use of TLV-Based Encoding for Efficiency ...................6
3. PA-TNC Message Protocol .........................................7
3.1. PA-TNC Messaging Model .....................................7
3.2. PA-TNC Relationship to PB-TNC ..............................8
3.3. PB-PA Posture Collector and Posture Validator
Identifiers ...............................................10
3.4. PA-TNC Messages in PB-TNC .................................10
3.5. IETF Standard PA Subtypes .................................11
3.6. PA-TNC Message Header Format ..............................12
4. PA-TNC Attributes ..............................................13
4.1. PA-TNC Attribute Header ..................................13
4.2. IETF Standard PA-TNC Attribute Types .....................17
4.2.1. Attribute Request ..................................18
4.2.2. Product Information ................................20
4.2.3. Numeric Version ....................................22
4.2.4. String Version .....................................24
4.2.5. Operational Status .................................26
4.2.6. Port Filter ........................................29
4.2.7. Installed Packages .................................31
4.2.8. PA-TNC Error .......................................34
4.2.9. Assessment Result ..................................41
4.2.10. Remediation Instructions ..........................42
4.2.11. Forwarding Enabled ................................45
4.2.12. Factory Default Password Enabled ..................47
4.3. Vendor-Defined Attributes ................................48
5. Security Considerations ........................................48
5.1. Trust Relationships .......................................48
1. Introduction ....................................................4
1.1. Prerequisites ..............................................4
1.2. Message Diagram Conventions ................................4
1.3. Conventions Used in This Document ..........................4
2. Design Considerations ...........................................4
2.1. Standard Attribute Namespace for Interoperability ..........4
2.2. Vendor-Defined Namespace for Differentiation and Agility ...5
2.3. Use of TLV-Based Encoding for Efficiency ...................6
3. PA-TNC Message Protocol .........................................7
3.1. PA-TNC Messaging Model .....................................7
3.2. PA-TNC Relationship to PB-TNC ..............................8
3.3. PB-PA Posture Collector and Posture Validator
Identifiers ...............................................10
3.4. PA-TNC Messages in PB-TNC .................................10
3.5. IETF Standard PA Subtypes .................................11
3.6. PA-TNC Message Header Format ..............................12
4. PA-TNC Attributes ..............................................13
4.1. PA-TNC Attribute Header ..................................13
4.2. IETF Standard PA-TNC Attribute Types .....................17
4.2.1. Attribute Request ..................................18
4.2.2. Product Information ................................20
4.2.3. Numeric Version ....................................22
4.2.4. String Version .....................................24
4.2.5. Operational Status .................................26
4.2.6. Port Filter ........................................29
4.2.7. Installed Packages .................................31
4.2.8. PA-TNC Error .......................................34
4.2.9. Assessment Result ..................................41
4.2.10. Remediation Instructions ..........................42
4.2.11. Forwarding Enabled ................................45
4.2.12. Factory Default Password Enabled ..................47
4.3. Vendor-Defined Attributes ................................48
5. Security Considerations ........................................48
5.1. Trust Relationships .......................................48
5.1.1. Posture Collector ..................................49
5.1.2. Posture Validator ..................................49
5.1.3. Posture Broker Client, Posture Broker Server .......49
5.2. Security Threats ..........................................50
5.2.1. Attribute Theft ....................................50
5.2.2. Message Fabrication ................................51
5.2.3. Attribute Modification .............................51
5.2.4. Attribute Replay ...................................52
5.2.5. Attribute Insertion ................................52
5.2.6. Denial of Service ..................................53
6. Privacy Considerations .........................................53
7. IANA Considerations ............................................54
7.1. Designated Expert Guidelines ..............................55
7.2. PA Subtypes ...............................................56
7.3. Registry for PA-TNC Attribute Types .......................56
7.4. Registry for PA-TNC Error Codes ...........................57
7.5. Registry for PA-TNC Remediation Parameters Types ..........58
8. Acknowledgments ................................................58
9. References .....................................................59
9.1. Normative References ......................................59
9.2. Informative References ....................................59
Appendix A. Use Cases .............................................60
A.1. Initial Client-Triggered Assessment .......................60
A.2. Server-Initiated Assessment with Remediation ..............64
A.3. Client-Triggered Reassessment .............................71
Appendix B. Evaluation against NEA Requirements ...................77
B.1. Evaluation against Requirements C-1 .......................77
B.2. Evaluation against Requirements C-2 .......................77
B.3. Evaluation against Requirements C-3 .......................77
B.4. Evaluation against Requirements C-4 .......................78
B.5. Evaluation against Requirements C-5 .......................78
B.6. Evaluation against Requirements C-6 .......................78
B.7. Evaluation against Requirements C-7 .......................79
B.8. Evaluation against Requirements C-8 .......................79
B.9. Evaluation against Requirements C-9 .......................79
B.10. Evaluation against Requirements C-10 .....................80
B.11. Evaluation against Requirements C-11 .....................80
B.12. Evaluation against Requirements PA-1 .....................81
B.13. Evaluation against Requirements PA-2 .....................81
B.14. Evaluation against Requirements PA-3 .....................81
B.15. Evaluation against Requirements PA-4 .....................82
B.16. Evaluation against Requirements PA-5 .....................82
B.17. Evaluation against Requirements PA-6 .....................83
5.1.1. Posture Collector ..................................49
5.1.2. Posture Validator ..................................49
5.1.3. Posture Broker Client, Posture Broker Server .......49
5.2. Security Threats ..........................................50
5.2.1. Attribute Theft ....................................50
5.2.2. Message Fabrication ................................51
5.2.3. Attribute Modification .............................51
5.2.4. Attribute Replay ...................................52
5.2.5. Attribute Insertion ................................52
5.2.6. Denial of Service ..................................53
6. Privacy Considerations .........................................53
7. IANA Considerations ............................................54
7.1. Designated Expert Guidelines ..............................55
7.2. PA Subtypes ...............................................56
7.3. Registry for PA-TNC Attribute Types .......................56
7.4. Registry for PA-TNC Error Codes ...........................57
7.5. Registry for PA-TNC Remediation Parameters Types ..........58
8. Acknowledgments ................................................58
9. References .....................................................59
9.1. Normative References ......................................59
9.2. Informative References ....................................59
Appendix A. Use Cases .............................................60
A.1. Initial Client-Triggered Assessment .......................60
A.2. Server-Initiated Assessment with Remediation ..............64
A.3. Client-Triggered Reassessment .............................71
Appendix B. Evaluation against NEA Requirements ...................77
B.1. Evaluation against Requirements C-1 .......................77
B.2. Evaluation against Requirements C-2 .......................77
B.3. Evaluation against Requirements C-3 .......................77
B.4. Evaluation against Requirements C-4 .......................78
B.5. Evaluation against Requirements C-5 .......................78
B.6. Evaluation against Requirements C-6 .......................78
B.7. Evaluation against Requirements C-7 .......................79
B.8. Evaluation against Requirements C-8 .......................79
B.9. Evaluation against Requirements C-9 .......................79
B.10. Evaluation against Requirements C-10 .....................80
B.11. Evaluation against Requirements C-11 .....................80
B.12. Evaluation against Requirements PA-1 .....................81
B.13. Evaluation against Requirements PA-2 .....................81
B.14. Evaluation against Requirements PA-3 .....................81
B.15. Evaluation against Requirements PA-4 .....................82
B.16. Evaluation against Requirements PA-5 .....................82
B.17. Evaluation against Requirements PA-6 .....................83
This document specifies PA-TNC, a Posture Attribute (PA) Protocol identical to the Trusted Computing Group's IF-M 1.0 protocol [8]. The document then evaluates PA-TNC against the requirements defined in the Network Endpoint Assessment (NEA) Requirements specification [9].
本文档指定了PA-TNC，这是一种姿态属性（PA）协议，与可信计算组的IF-M 1.0协议相同[8]。然后，该文件根据网络端点评估（NEA）需求规范[9]中定义的需求评估PA-TNC。
This document does not define an architecture or reference model. Instead, it defines a protocol that works within the reference model described in the NEA Overview and Requirements specification. The reader is assumed to be thoroughly familiar with that document. No familiarity with TCG specifications is assumed.
本文档未定义架构或参考模型。相反，它定义了在NEA概述和需求规范中描述的参考模型内工作的协议。假定读者完全熟悉该文件。假设不熟悉TCG规范。
This specification defines the syntax of PA-TNC 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.
本规范使用图表定义PA-TNC消息的语法。每个图表以位为单位描述每个字段的格式和大小。实现必须按照所示发送每个图中的位，从上到下遍历图，然后在每行中从左到右遍历（表示32位的数量）。表示数值的多字节字段必须以网络（大端）字节顺序发送。
Descriptions of bit field (e.g., flag) values are described referring to the position of the bit within the field. These bit positions are numbered from the most significant bit through the least significant bit, so a 1-octet field with only bit 0 set has the value 0x80.
比特字段（例如，标志）值的描述参考比特在字段中的位置来描述。这些位位置从最高有效位到最低有效位进行编号，因此仅设置了位0的1-octet字段的值为0x80。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
This section discusses some of the key design considerations for the PA protocol.
本节讨论PA协议的一些关键设计注意事项。
The PA protocol requires the use of two categories of namespaces: component types (AKA PA subtypes) and attributes. Each of these namespace categories needs to contain well-known, interoperable names with defined syntax and semantics co-existing with names for vendor-
PA协议需要使用两类名称空间：组件类型（又名PA子类型）和属性。这些名称空间类别中的每一个都需要包含知名的、可互操作的名称，这些名称具有定义的语法和语义，并与供应商的名称共存-
defined private extensions. Similarly, each namespace category needs to be readily extensible without repeated coordination yet avoids naming conflicts.
定义的私有扩展。类似地，每个名称空间类别都需要易于扩展，无需重复协调，同时避免命名冲突。
The PA-TNC and PB-TNC protocols provide for multiple orthogonal namespaces for each category that exist without overlap by including a Structure of Management Information (SMI) Private Enterprise Number (PEN) field to identify the definer of namespace of the associated field. This allows the IETF NEA WG to define a set of standard component types and attribute types while allowing vendors to each create additional names outside of the IETF standard namespace. Over time, vendor-defined names might be proposed for standardization and thus migration into the IETF namespace.
PA-TNC和PB-TNC协议通过包括管理信息结构（SMI）私有企业编号（PEN）字段来标识相关字段的名称空间的定义人，为存在的每个类别提供了多个正交名称空间，而没有重叠。这允许IETF NEA WG定义一组标准组件类型和属性类型，同时允许供应商在IETF标准名称空间之外创建其他名称。随着时间的推移，可能会建议供应商定义的名称进行标准化，从而迁移到IETF名称空间。
The PB-TNC protocol defines an IETF standard namespace (using vendor-id=0) that allows for definition of standard component types (e.g., Operating System, Firewall, Anti-Virus) using the PA Subtype field (see section 3.2). Similarly, PA-TNC defines a set of standard attributes in section 4.2 that represent the most common capabilities (attributes) of these types of components across a variety of vendor implementations. The standard namespace allows NEA deployments with both open source and vendor-provided NEA implementations to support a consistent set of policies across their environment based on these standard attributes. The standard attributes can be used with a variety of endpoints (hosts, printers, mobile devices) that are running applications and operating systems (defined by the PA subtypes) from a variety of vendors.
PB-TNC协议定义了IETF标准名称空间（使用供应商id=0），允许使用PA子类型字段定义标准组件类型（例如，操作系统、防火墙、防病毒）（见第3.2节）。类似地，PA-TNC在第4.2节中定义了一组标准属性，这些属性表示各种供应商实现中这些类型组件的最常见功能（属性）。标准名称空间允许使用开放源代码和供应商提供的NEA实现的NEA部署基于这些标准属性在其整个环境中支持一组一致的策略。标准属性可用于运行来自不同供应商的应用程序和操作系统（由PA子类型定义）的各种端点（主机、打印机、移动设备）。
The endpoint is a very dynamic environment in terms of rate of new features being deployed and attacks that are crafted against existing and new applications such as viruses, worms, malware, and spyware. It is difficult to imagine the standard namespaces being able to keep pace with this rapidly changing environment. Vendors typically differentiate themselves by moving rapidly to provide unique mechanisms to address such threats and their ability to deal with changes in an agile manner. The PA-TNC and PB-TNC protocols allow for creation of vendor-defined namespace(s) where each namespace allows use of vendor-defined PA subtypes to identify non-standard applications or operating system variants and vendor-defined attributes describing new aspects of each type of component. The vendor namespaces will allow NEA deployments to craft compliance policies using a mixture of attributes from both the IETF standard namespace and vendor-defined namespaces that may include multiple vendors representing the various hardware and software components present on the endpoints.
就部署新功能的速度以及针对现有和新应用程序（如病毒、蠕虫、恶意软件和间谍软件）的攻击而言，端点是一个非常动态的环境。很难想象标准名称空间能够跟上这种快速变化的环境。供应商通常会迅速采取行动，提供独特的机制来应对这些威胁，并以敏捷的方式处理变化，从而使自己与众不同。PA-TNC和PB-TNC协议允许创建供应商定义的名称空间，其中每个名称空间允许使用供应商定义的PA子类型来识别非标准应用程序或操作系统变体，以及描述每种组件新方面的供应商定义属性。供应商名称空间将允许NEA部署使用IETF标准名称空间和供应商定义名称空间的混合属性制定合规性政策，这些名称空间可能包括多个代表端点上各种硬件和软件组件的供应商。
The PA-TNC protocol's use of vendor-id to identify the namespace of each attribute allows Posture Collectors to support some or all of the IETF standard attributes plus optionally a set of vendor-defined attributes (potentially from more than one vendor-id namespace). For instance, an open source anti-virus Posture Collector might be written that supports all of the IETF standard attributes used to describe a local anti-virus component and a subset of multiple anti-virus manufacturers' vendor-defined attributes. This Posture Collector might therefore be able to interoperate with Posture Validators from multiple vendors. Conversely, a simple Posture Collector might be written to ignore any vendor-defined attributes requested and only return standard attributes that it supports. If the vendor-provided Posture Validator's policy allows for this subset to be considered compliant, then these simple Posture Collectors can be used to perform a successful assessment.
PA-TNC协议使用供应商id标识每个属性的名称空间，允许姿态收集器支持部分或全部IETF标准属性，以及可选的一组供应商定义的属性（可能来自多个供应商id名称空间）。例如，可以编写一个开源防病毒姿态收集器，该收集器支持用于描述本地防病毒组件的所有IETF标准属性和多个防病毒制造商供应商定义属性的子集。因此，此姿态收集器可能能够与来自多个供应商的姿态验证器进行互操作。相反，可以编写一个简单的姿态收集器来忽略所请求的任何供应商定义的属性，只返回它支持的标准属性。如果供应商提供的姿势验证器策略允许此子集被视为符合要求，则可以使用这些简单的姿势收集器来执行成功的评估。
The PA-TNC protocol has chosen to employ a binary encoding using a type-length-value (TLV) structure. TLV encoding was preferred over the use of a textual encoding format such as XML to provide a more efficient utilization of the potentially constrained bandwidth available between the NEA Client and NEA Server (see NEA Overview and Architecture [9]). Efficiency was a primary criterion for this choice with consideration given to both:
PA-TNC协议选择使用类型长度值（TLV）结构的二进制编码。与使用文本编码格式（如XML）相比，首选TLV编码，以便更有效地利用NEA客户端和NEA服务器之间可能受限的带宽（参见NEA概述和体系结构[9]）。效率是这一选择的主要标准，同时考虑了以下两个方面：
1. Optimization of the bits-on-the-wire to accommodate NEA requirements for assessment over low bandwidth or high latency links (C-8) and allow for the Posture Transport (PT) protocol to run over existing network access protocols (PT-4, C-11) that are constrained by packet size.
1. 优化线路上的位，以适应NEA对低带宽或高延迟链路（C-8）评估的要求，并允许姿态传输（PT）协议在受数据包大小限制的现有网络访问协议（PT-4、C-11）上运行。
2. Optimization of CPU utilization on the endpoint to accommodate for low power endpoints such as mobile devices.
2. 优化端点上的CPU利用率，以适应低功耗端点，如移动设备。
The choice of TLV encoding does not preclude the use of XML-based attribute values within the vendor namespaces or future standard attributes. It is conceivable that certain vendors may utilize XML encoding for extensibility within their namespace when the above considerations are less applicable to their technologies. Attributes encoded within the vendor-defined namespace using alternate encoding such as XML will be opaque to NEA software only supporting standard attributes and will be processed primarily by the vendor-defined components (collector/validator).
TLV编码的选择并不排除在供应商名称空间或未来的标准属性中使用基于XML的属性值。可以想象，当上述考虑不太适用于他们的技术时，某些供应商可能会利用XML编码在他们的名称空间内实现可扩展性。在供应商定义的名称空间中使用替代编码（如XML）编码的属性对于仅支持标准属性的NEA软件来说是不透明的，并且将主要由供应商定义的组件（收集器/验证器）处理。
This section discusses the use of the PA-TNC message and its attributes, and specifies the syntax and semantics for the PA-TNC message header. The details of each attribute included within the PA-TNC payload are specified in section 4.2.
本节讨论PA-TNC消息及其属性的使用，并指定PA-TNC消息头的语法和语义。第4.2节规定了PA-TNC有效载荷中包含的每个属性的详细信息。
PA-TNC messages are carried by the PB-TNC protocol [5], which provides a multi-roundtrip reliable transport and end-to-end message delivery to subscribed (interested) parties using a variety of underlying network protocols. PA-TNC is unaware of these underlying PT protocols being used below PB-TNC.
PA-TNC消息由PB-TNC协议[5]承载，该协议使用各种底层网络协议向订阅方（感兴趣方）提供多回程可靠传输和端到端消息传递。PA-TNC不知道PB-TNC下面正在使用这些基础PT协议。
The interested parties consist of Posture Collectors on the NEA Client and Posture Validators associated with the NEA Server that have registered to receive messages about particular types of components (e.g., anti-virus) during an assessment. The PA-TNC messaging protocol operates synchronously within an assessment session, with Posture Collectors and Posture Validators taking turns sending one or more messages to each other. Each PA-TNC message may contain one or more attributes associated with the functional component identified in the component type (PA Subtype) of the Posture Broker (PB) protocol.
相关方包括NEA客户端上的姿态采集器和与NEA服务器相关联的姿态验证器，这些姿态验证器已注册以在评估期间接收关于特定类型组件（例如，防病毒）的消息。PA-TNC消息传递协议在评估会话中同步运行，姿势收集器和姿势验证器轮流向彼此发送一条或多条消息。每个PA-TNC消息可以包含与姿势代理（PB）协议的组件类型（PA子类型）中标识的功能组件相关联的一个或多个属性。
Posture Collectors may only send PA-TNC messages to Posture Validators and vice versa. No Posture Collector-to-Posture Collector or Posture Validator-to-Posture Validator messaging is allowed to occur. Each Posture Collector or Posture Validator may send several PA-TNC messages in succession before indicating that it has completed its batch of messages to the Posture Broker Client or Posture Broker Server respectively. As necessary, the Posture Broker Client and Posture Broker Server will batch these messages prior to sending them over the network.
姿态采集器只能向姿态验证器发送PA-TNC消息，反之亦然。不允许发生姿势收集器到姿势收集器或姿势验证器到姿势验证器的消息传递。每个姿态采集器或姿态验证器在分别向姿态代理客户端或姿态代理服务器指示其已完成其消息批之前，可以连续发送多个PA-TNC消息。如有必要，姿态代理客户端和姿态代理服务器将在通过网络发送消息之前对这些消息进行批处理。
PB-TNC provides a publish/subscribe model of message exchange. This means that, at any given point in time, zero or more subscribers for a particular type of message may be present on a Posture Broker Client or Posture Broker Server. This is beneficial, since it allows one Posture Collector or Posture Validator to combine multiple functions (like anti-virus and personal firewall) by subscribing to both TNC standard component types. It also allows multiple Posture Collectors or Posture Validators to support the same components, such as two anti-virus Posture Validators that are each used to manage their own respective anti-virus client software.
PB-TNC提供了消息交换的发布/订阅模型。这意味着，在任何给定的时间点，特定类型消息的零个或多个订阅者可能出现在姿态代理客户端或姿态代理服务器上。这是有益的，因为它允许一个姿态收集器或姿态验证器通过订阅两种TNC标准组件类型来组合多种功能（如防病毒和个人防火墙）。它还允许多个姿态采集器或姿态验证器支持相同的组件，例如两个防病毒姿态验证器，每个用于管理各自的防病毒客户端软件。
However, this publish/subscribe model has some possible negative side effects. When a Posture Collector or Posture Validator initially sends a PA-TNC message, it does not know whether it will receive many, one, or no PA-TNC messages from the other side. For many types of assessments, this is acceptable, but in some cases a more direct channel binding between a particular Posture Collector and Posture Validator pair is necessary. For example, a Posture Validator may wish to provide remediation instructions to a particular Posture Collector that it knows is capable of remediating a non-compliant component. This can be accomplished using the exclusive delivery PB-TNC capability to limit distribution of a message to a single Posture Collector by including the target Posture Collector Identifier in the PB-PA header. For more information on the PB-PA header, see section 4.5 of the PB-TNC specification.
然而，这种发布/订阅模式可能有一些负面影响。当姿态采集器或姿态验证器最初发送PA-TNC消息时，它不知道是否会从另一端接收多个、一个或没有PA-TNC消息。对于许多类型的评估，这是可以接受的，但在某些情况下，特定姿势收集器和姿势验证器对之间需要更直接的通道绑定。例如，姿势验证器可能希望向其知道能够修正不符合组件的特定姿势收集器提供修正指令。这可以通过使用专用传送PB-TNC功能来实现，该功能通过在PB-PA报头中包含目标姿态收集器标识符来限制消息向单个姿态收集器的分发。有关PB-PA集管的更多信息，请参阅PB-TNC规范第4.5节。
This section summarizes the major elements of a PA-TNC message as they might appear inside of a PB-TNC message. The double line (===) in the diagram below indicates the separation between the PB-TNC and PA-TNC protocols. The PA-TNC portion of the message is delivered to each Posture Collector or Posture Validator registered to receive messages containing a particular message type. Note that PB-TNC is capable of carrying multiple PB-TNC and PA-TNC messages in a single PB-TNC batch. See the PB-TNC specification [5] for more information on its capabilities.
本节总结了PA-TNC消息的主要元素，因为它们可能出现在PB-TNC消息中。下图中的双线（==）表示PB-TNC和PA-TNC协议之间的分离。消息的PA-TNC部分被传递到注册以接收包含特定消息类型的消息的每个姿势收集器或姿势验证器。请注意，PB-TNC能够在单个PB-TNC批处理中承载多个PB-TNC和PA-TNC消息。有关其功能的更多信息，请参见PB-TNC规范[5]。
One important linkage between the PA-TNC and PB-TNC protocols is the PA message type (PA Message Vendor ID and PA Subtype) that is used by the Posture Broker Client and Posture Broker Server to route messages to interested Posture Collectors and Posture Validators. The message type indicates the software component (component type) that is associated with the attributes included inside the PA-TNC message. Therefore, Posture Collectors and Posture Validators written to support an assessment of a particular component can register to receive messages about the component and thus participate in its assessment. Each Posture Collector and Posture Validator MUST only send PA-TNC messages containing attributes that pertain to the software component defined in the message type of the message. This ensures that only the appropriate Posture Collectors and Posture Validators that support a particular type of component will receive attributes related to that component. If a PA-TNC message contained a mix of attributes about different components and a message type of only one of those components, the message would only be delivered to parties interested in the component type included in the message type, so other interested recipients wouldn't see those attributes.
PA-TNC和PB-TNC协议之间的一个重要联系是PA消息类型（PA消息供应商ID和PA子类型），姿态代理客户端和姿态代理服务器使用该类型将消息路由到感兴趣的姿态收集器和姿态验证器。消息类型表示与PA-TNC消息中包含的属性相关联的软件组件（组件类型）。因此，为支持特定组件的评估而编写的姿势收集器和姿势验证器可以注册以接收关于该组件的消息，从而参与其评估。每个姿态采集器和姿态验证器必须仅发送PA-TNC消息，该消息包含与消息类型中定义的软件组件相关的属性。这确保只有支持特定类型组件的适当姿势收集器和姿势验证器才会接收与该组件相关的属性。如果PA-TNC消息包含关于不同组件的混合属性和仅包含其中一个组件的消息类型，则消息将仅传递给对消息类型中包含的组件类型感兴趣的各方，因此其他感兴趣的收件人将看不到这些属性。
The message type is composed of two fields: a PA Message Vendor ID and a PA Subtype. The PA Message Vendor ID identifies the vendor or other organization that defined this message type. The PA Subtype identifies the message type more specifically within the set of message types defined by that vendor. This specification defines several IETF Standard PA Subtypes to be used with a PA Message Vendor ID of zero (0). Within this specification, the PA Subtype field is used to indicate the type of component (e.g., firewall) involved with the message's attributes. Therefore, for clarity, the PA subtype will be referred to as the "component type" in this specification. Vendor-defined namespaces may use other semantics for the PA Subtype field as this is outside the scope of this specification.
消息类型由两个字段组成：PA消息供应商ID和PA子类型。PA消息供应商ID标识定义此消息类型的供应商或其他组织。PA子类型在该供应商定义的消息类型集中更具体地标识消息类型。本规范定义了几个IETF标准PA子类型，用于PA消息供应商ID为零（0）的情况。在本规范中，PA子类型字段用于指示与消息属性相关的组件类型（如防火墙）。因此，为清楚起见，本规范中将PA子类型称为“组件类型”。供应商定义的名称空间可能会对PA子类型字段使用其他语义，因为这超出了本规范的范围。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Message of type PB-PA-Message |
|(includes PA Message Vendor ID, PA Subtype, and other fields |
| used by Posture Broker Client and Posture Broker Server for |
| routing) |
===============================================================
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Message Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute |
| (e.g., Product Information) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute |
| (e.g., Operational Status) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Message of type PB-PA-Message |
|(includes PA Message Vendor ID, PA Subtype, and other fields |
| used by Posture Broker Client and Posture Broker Server for |
| routing) |
===============================================================
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Message Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute |
| (e.g., Product Information) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute |
| (e.g., Operational Status) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Overview of a PB-TNC batch that contains a PA-TNC message
图1。包含PA-TNC消息的PB-TNC批处理概述
For example, if a Posture Broker Client sent a PB-TNC batch that contained a PA-TNC message with a message type indicating firewall component, this message would be routed by the Posture Broker Server to Posture Validators registered to assess firewalls. Each registered Posture Validator would receive a copy of the PA-TNC message including the PA-TNC header and set of attributes. It is important that each of the attributes included in the PA-TNC message be associated with the firewall component because only the Posture Collector and Posture Validator interested in firewalls will receive such messages.
例如，如果姿态代理客户端发送了包含PA-TNC消息（消息类型指示防火墙组件）的PB-TNC批处理，该消息将由姿态代理服务器路由到注册以评估防火墙的姿态验证器。每个注册的姿态验证器将接收一份PA-TNC消息的副本，包括PA-TNC头和一组属性。PA-TNC消息中包含的每个属性都必须与防火墙组件相关联，这一点很重要，因为只有对防火墙感兴趣的姿态收集器和姿态验证器才会接收此类消息。
If the above message contained both firewall and operating system attributes inside a PA-TNC message with a component type of firewall, then any Posture Collector and Posture Validator registered to receive operating system messages would not receive those attributes, as the messages would only be delivered to those registered for firewall messages.
如果上述消息在组件类型为防火墙的PA-TNC消息中同时包含防火墙和操作系统属性，则注册用于接收操作系统消息的任何姿态收集器和姿态验证器都不会接收这些属性，因为这些消息只会传递给那些注册防火墙消息的人。
The PB-PA header contains several fields important to the processing of a received PA message. The PA Vendor ID and Subtype are described in the PB-TNC specification and above in section 3.2. Also present in the PB-PA header is a pair of fields that identify the Posture Collector and/or Posture Validator involved in the exchange. These fields are used for performing exclusive delivery of messages as described in section 3.1 and as an indicator for correlation of received attributes.
PB-PA报头包含几个对处理接收到的PA消息很重要的字段。PA供应商ID和子类型在PB-TNC规范和以上第3.2节中进行了描述。PB-PA标头中还存在一对字段，用于标识交换中涉及的姿势收集器和/或姿势验证器。这些字段用于执行第3.1节所述的消息的独占传递，并作为接收属性相关性的指标。
Correlation of attributes is necessary when the sending Posture Collector provides posture for multiple implementations of a single type of component during an assessment, so the recipient Posture Validators need to know which attributes are describing the same implementation.
当发送姿态采集器在评估期间为单一类型组件的多个实现提供姿态时，属性的关联是必要的，因此接收方姿态验证器需要知道哪些属性描述相同的实现。
For example, a single Posture Collector might report attributes on two installed VPN implementations on the endpoint. Because the individual attributes do not include an indication of which VPN product they are describing, the recipient needs something to perform this correlation. Therefore, for this example, the VPN Posture Collector would need to obtain two Posture Collector Identifiers from the Posture Broker Client and consistently use one with each of the implementations during an assessment. The VPN Posture Collector would group all the attributes associated with a particular VPN implementation into a single PB-PA message and send the message using the Posture Collector Identifier it designates as going with the particular implementation. This approach allows the recipient to recognize when attributes in future assessment messages also describe the same component implementation.
例如，单个姿态收集器可能会报告端点上两个已安装VPN实现的属性。由于各个属性不包括它们所描述的VPN产品的指示，因此收件人需要一些东西来执行此关联。因此，对于该示例，VPN姿态收集器将需要从姿态代理客户端获得两个姿态收集器标识符，并在评估期间对每个实现一致地使用一个。VPN姿态采集器将与特定VPN实现相关联的所有属性分组到单个PB-PA消息中，并使用其指定的姿态采集器标识符发送消息，该标识符与特定实现一致。这种方法允许接收者识别未来评估消息中的属性何时也描述了相同的组件实现。
As depicted in section 3.2, a PA-TNC message consists of a PA-TNC header followed by a sequence of one or more attributes. The PA-TNC message header (described in section 3.6) and the header for each of the PA-TNC attributes (specified in section 4.1) have a fixed type-length-value (TLV) format. Each PA-TNC message MAY contain a mixture of standards-based and vendor-defined attributes identifiable using the type portion of the attribute header. All Posture Collectors and
如第3.2节所述，PA-TNC消息由PA-TNC报头和一个或多个属性序列组成。PA-TNC消息头（在第3.6节中描述）和每个PA-TNC属性的头（在第4.1节中指定）具有固定类型长度值（TLV）格式。每个PA-TNC消息可以包含基于标准和供应商定义的属性的混合，这些属性可以使用属性头的类型部分进行识别。所有姿态收集器和
Posture Validators compliant with this specification MUST be capable of processing multiple attributes in a received PA-TNC message. A Posture Collector or Posture Validator that receives a PA-TNC message can use the attribute header's length field to skip any attributes that it does not understand, unless the attribute is marked as mandatory to process.
符合本规范的姿态验证器必须能够处理接收到的PA-TNC消息中的多个属性。接收PA-TNC消息的姿势收集器或姿势验证器可以使用属性头的长度字段跳过它不理解的任何属性，除非该属性被标记为必须处理。
This section defines several IETF Standard PA Subtypes. Each PA subtype defined here identifies a specific component relevant to the endpoint's posture. This allows a small set of generic PA-TNC attributes (e.g., Product Information) to be used to describe a large number of different components (e.g., operating system, anti-virus, etc.). It also allows Posture Collectors and Posture Validators to specialize in a particular component and only receive PA-TNC messages relevant to that component.
本节定义了几个IETF标准PA子类型。此处定义的每个PA子类型标识与端点姿势相关的特定组件。这允许使用一小部分通用PA-TNC属性（例如，产品信息）来描述大量不同的组件（例如，操作系统、防病毒等）。它还允许姿态采集器和姿态验证器专门处理特定组件，并且只接收与该组件相关的PA-TNC消息。
Value Integer Definition
----- ------- ----------
0 Testing Reserved for use in specification
examples, experimentation and
testing.
Value Integer Definition
----- ------- ----------
0 Testing Reserved for use in specification
examples, experimentation and
testing.
1 Operating System Operating system running on the endpoint
1操作系统在终结点上运行的操作系统
2 Anti-Virus Host-based anti-virus software
2基于主机的防病毒软件
3 Anti-Spyware Host-based anti-spyware software
3反间谍软件基于主机的反间谍软件
4 Anti-Malware Host-based anti-malware (e.g., anti-bot) software not included within anti-virus or anti-spyware components
4反恶意软件基于主机的反恶意软件（例如，反bot）软件不包括在反病毒或反间谍软件组件中
5 Firewall Host-based firewall
5基于主机的防火墙
6 IDPS Host-based Intrusion Detection and/or Prevention Software (IDPS)
6基于IDPS主机的入侵检测和/或预防软件（IDPS）
7 VPN Host-based Virtual Private Network (VPN) software
7基于VPN主机的虚拟专用网（VPN）软件
8 NEA Client NEA client software
8 NEA客户端NEA客户端软件
These PA subtypes must be used in a PB-PA message with a PA Message Vendor ID of zero (0) indicating an IETF standard type of component (as described in the PB-TNC specification [5]). If these PA subtype
这些PA子类型必须在PA消息供应商ID为零（0）的PB-PA消息中使用，表示组件的IETF标准类型（如PB-TNC规范[5]所述）。如果这些PA亚型
values are used with a different PA Message Vendor ID, they have a completely different meaning that is not defined in this specification. Posture Collectors and Posture Validators MUST NOT require support for particular vendor-specific PA subtypes and MUST interoperate with other parties despite any differences in the set of vendor-specific PA subtypes supported (although they MAY permit administrators to configure them to require support for specific PA subtypes).
值与不同的PA消息供应商ID一起使用，它们具有本规范中未定义的完全不同的含义。姿态采集器和姿态验证器不得要求对特定供应商特定PA子类型的支持，并且必须与其他方进行互操作，尽管所支持的供应商特定PA子类型集存在任何差异（尽管它们可能允许管理员将其配置为需要对特定PA子类型的支持）。
This section describes the format and semantics of the PA-TNC header.
Every PA-TNC message MUST start with a PA-TNC header. The PA-TNC
header provides a common context applying to all of the attributes
contained within the PA-TNC payload. The payload consists of a
sequence of assessment attributes described in section 4.2.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This section describes the format and semantics of the PA-TNC header.
Every PA-TNC message MUST start with a PA-TNC header. The PA-TNC
header provides a common context applying to all of the attributes
contained within the PA-TNC payload. The payload consists of a
sequence of assessment attributes described in section 4.2.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
版本
This field indicates the version of the format for the PA-TNC message. This version is intended to allow for evolution of the PA-TNC message header and payload in a manner that can easily be detected by message recipients.
此字段表示PA-TNC消息格式的版本。此版本旨在允许PA-TNC消息头和有效负载以消息接收者容易检测到的方式演变。
PA-TNC message senders MUST set this field to 0x01 for all PA-TNC messages that comply with this specification. Implementations responding to a PA-TNC message containing a supported version MUST use the same version number to minimize the risk of version incompatibility. Message recipients MUST respond to a PA-TNC message containing an unsupported version by sending a Version Not Supported error in a PA-TNC Error attribute that is the only PA-TNC attribute in a PA-TNC message with version number 1.
对于符合本规范的所有PA-TNC消息，PA-TNC消息发送者必须将此字段设置为0x01。响应包含受支持版本的PA-TNC消息的实现必须使用相同的版本号，以最小化版本不兼容的风险。邮件收件人必须通过在PA-TNC错误属性中发送版本不受支持的错误来响应包含不受支持版本的PA-TNC邮件，该错误是版本号为1的PA-TNC邮件中唯一的PA-TNC属性。
PA-TNC message initiators supporting multiple PA-TNC protocol versions SHOULD be able to alter which version of PA-TNC message they send based on prior message exchanges with a particular peer Posture Collector or Posture Validator.
支持多个PA-TNC协议版本的PA-TNC消息启动器应能够根据先前与特定对等姿态采集器或姿态验证器的消息交换来更改其发送的PA-TNC消息的版本。
Reserved
含蓄的
Reserved for future use. This field MUST be set to 0 on transmission and ignored upon reception.
保留供将来使用。此字段在传输时必须设置为0，在接收时忽略。
Message Identifier
消息标识符
This field contains a value that uniquely identifies this message, differentiating it from others sent by a particular PA-TNC message sender within this assessment. This value can be included in the payload of a response message to indicate which message was received and caused the response. This value is included in the payload of PA-TNC error messages so the party who receives the error message can determine which of the messages they had sent caused the error.
此字段包含唯一标识此邮件的值，将其与此评估中特定PA-TNC邮件发件人发送的其他邮件区分开来。该值可以包含在响应消息的有效负载中，以指示接收到并导致响应的消息。该值包含在PA-TNC错误消息的有效负载中，因此接收错误消息的一方可以确定他们发送的消息中的哪一条导致了错误。
PA-TNC message senders MUST NOT send the same message identifier more than once during an assessment. Message identifiers may be randomly generated or sequenced as long as values are not repeated during an assessment message exchange. PA-TNC message recipients are not required to check for duplicate message identifiers.
PA-TNC消息发送者在评估期间不得多次发送相同的消息标识符。只要在评估消息交换期间不重复值，消息标识符可以随机生成或排序。PA-TNC邮件收件人无需检查重复的邮件标识符。
This section defines the PA-TNC attributes that can be carried within a PA-TNC message. The initial section defines the standard attribute header that appears at the start of each attribute in a PA-TNC message. The second section defines each of the IETF Standard PA-TNC Attributes and the final section discusses how vendor-defined PA-TNC attributes can be used within a PA-TNC message. Vendor-defined PA-TNC attributes use the vendor's SMI Private Enterprise Number in the Attribute Type field.
本节定义了可在PA-TNC消息中携带的PA-TNC属性。初始部分定义出现在PA-TNC消息中每个属性开头的标准属性头。第二节定义了IETF标准PA-TNC属性，最后一节讨论了如何在PA-TNC消息中使用供应商定义的PA-TNC属性。供应商定义的PA-TNC属性在属性类型字段中使用供应商的SMI私有企业编号。
A PA-TNC message MUST contain a PA-TNC header (defined in section 3.6. followed by a sequence of zero or more PA-TNC attributes. All PA-TNC attributes MUST begin with a standard PA-TNC attribute header, as defined in section 4.1. The contents of PA-TNC attributes vary widely, depending on their attribute type. Section 4.2 defines the IETF Standard PA-TNC Attributes. Section 4.3 discusses how vendor-specific PA-TNC attributes can be defined.
PA-TNC消息必须包含PA-TNC头（定义见第3.6节。后面是一系列零或多个PA-TNC属性。所有PA-TNC属性必须以标准PA-TNC属性头开头，如第4.1节所定义。PA-TNC属性的内容因属性类型而异。第4.2节定义了IETF标准PA-TNC属性。第4.3节讨论了如何可以定义特定于供应商的PA-TNC属性。
Following the PA-TNC message header is a sequence of zero or more attributes. All PA-TNC attributes MUST begin with the standard PA-TNC attribute header defined in this subsection. Each attribute described in this specification is represented by a TLV tuple. The TLV tuple includes an attribute identifier comprised of the Vendor ID
PA-TNC消息头后面是一系列零或多个属性。所有PA-TNC属性必须以本小节中定义的标准PA-TNC属性头开头。本规范中描述的每个属性都由TLV元组表示。TLV元组包括由供应商ID组成的属性标识符
and Attribute Type (type), the TLV tuple's overall length, and finally the attribute's value. The use of TLV representation was chosen due to its flexibility and extensibility and use in other standards. Recipients of an attribute can use the attribute type fields to determine the precise syntax and semantics of the attribute value field and the length to skip over an unrecognized attribute. The length field is also beneficial when a variable-length attribute value is provided.
属性类型（Type），TLV元组的总长度，最后是属性的值。选择使用TLV表示是因为它的灵活性和可扩展性以及在其他标准中的使用。属性的接收者可以使用属性类型字段来确定属性值字段的精确语法和语义，以及跳过未识别属性的长度。当提供可变长度属性值时，长度字段也很有用。
The TLV format does not contain an explicit TLV format version number, so every attribute included in a particular PA-TNC message MUST use the same TLV format. Using the PA-TNC message version number to indicate the format of all TLV attributes within a PA-TNC message allows for future versioning of the TLV format in a manner detectable by PA-TNC message recipients. Similarly, requiring all TLV attribute formats to be the same within a PA-TNC message also ensures that recipients compliant with a particular PA-TNC message version can at least parse every attribute header and use the length to skip over unrecognized attributes. Finally, all attribute TLVs within a PA-TNC message MUST pertain to the same implementation of the component. This restriction is relevant when a single Posture Collector is reporting on multiple implementations of a component, so must send multiple PA-TNC messages each including only the attributes describing a single implementation. For more information on how Posture Collectors should handle multiple implementations, see section 3.3.
TLV格式不包含明确的TLV格式版本号，因此特定PA-TNC消息中包含的每个属性都必须使用相同的TLV格式。使用PA-TNC消息版本号指示PA-TNC消息中所有TLV属性的格式，允许将来以PA-TNC消息接收者可检测的方式对TLV格式进行版本控制。类似地，要求PA-TNC消息中的所有TLV属性格式相同也可以确保符合特定PA-TNC消息版本的收件人至少可以解析每个属性头，并使用长度跳过无法识别的属性。最后，PA-TNC消息中的所有属性TLV必须属于组件的同一实现。当单个姿态采集器报告组件的多个实现时，此限制是相关的，因此必须发送多个PA-TNC消息，每个消息仅包括描述单个实现的属性。有关姿态采集器应如何处理多个实现的更多信息，请参见第3.3节。
Every PA-TNC-compliant TLV attribute MUST use the following TLV
format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | PA-TNC Attribute Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Value (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Every PA-TNC-compliant TLV attribute MUST use the following TLV
format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | PA-TNC Attribute Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Value (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags
旗帜
This field defines flags impacting the processing of the associated attribute.
此字段定义影响关联属性处理的标志。
Bit 0 (0x80) is the NOSKIP flag. Any Posture Collector or Posture Validator that receives an attribute with this flag set to 1 but does not support this attribute MUST NOT process any part of the PA-TNC message and SHOULD respond with an Attribute Type Not Supported error in a PA-TNC error message.
位0（0x80）是NOSKIP标志。接收此标志设置为1但不支持此属性的属性的任何姿势收集器或姿势验证器不得处理PA-TNC消息的任何部分，并应在PA-TNC错误消息中以属性类型不支持的错误进行响应。
In order to avoid taking action on a subset of the attributes only to later find an unsupported attribute with the NOSKIP flag set, recipients of a multi-attribute PA-TNC message might need to scan all of the attributes prior to acting upon any attribute.
为了避免在属性子集上执行操作后仅查找设置了NOSKIP标志的不受支持的属性，多属性PA-TNC消息的收件人可能需要在对任何属性执行操作之前扫描所有属性。
When the NOSKIP flag is set to 0, recipients SHOULD skip any unsupported attributes and continue processing the next attribute.
当NOSKIP标志设置为0时，收件人应跳过任何不支持的属性，并继续处理下一个属性。
Bit 1-7 are reserved for future use. These bits MUST be set to 0 on transmission and ignored upon reception.
位1-7保留供将来使用。这些位在传输时必须设置为0，在接收时必须忽略。
PA-TNC Attribute Vendor ID
PA-TNC属性供应商ID
This field indicates the owner of the namespace associated with the PA-TNC Attribute Type. This is accomplished by specifying the 24-bit SMI Private Enterprise Number Vendor ID of the party who owns the Attribute Type namespace. IETF Standard PA-TNC Attribute Types MUST use zero (0) in this field.
此字段表示与PA-TNC属性类型关联的命名空间的所有者。这是通过指定拥有属性类型命名空间的一方的24位SMI私有企业号供应商ID来实现的。IETF标准PA-TNC属性类型在此字段中必须使用零（0）。
The PA-TNC Attribute Vendor ID 0xffffff is reserved. Posture Collectors and Posture Validators MUST NOT send PA-TNC messages in which the PA-TNC Attribute Vendor ID has this reserved value (0xffffff). If a Posture Collector or Posture Validator receives a message in which the PA-TNC Attribute Vendor ID has this reserved value (0xffffff), it SHOULD respond with an Invalid Parameter error code in a PA-TNC Error attribute.
PA-TNC属性供应商ID 0xffffff是保留的。姿态采集器和姿态验证器不得发送PA-TNC属性供应商ID具有此保留值（0xffffff）的PA-TNC消息。如果姿态采集器或姿态验证器接收到PA-TNC属性供应商ID具有此保留值（0xffffff）的消息，则它应以PA-TNC错误属性中的无效参数错误代码进行响应。
PA-TNC Attribute Type
PA-TNC属性类型
This field defines the type of the attribute included in the Attribute Value field. This field is qualified by the PA-TNC Attribute Vendor ID field so that a particular PA-TNC Attribute Type value (e.g., 327) has a completely different meaning depending on the value in the PA-TNC Attribute Vendor ID field. Posture Collectors and Posture Validators MUST NOT require support for particular vendor-specific PA-TNC Attribute Types and MUST interoperate with other parties despite any differences in the set of vendor-specific PA-TNC Attribute Types supported (although they MAY permit administrators to configure them to require support for specific PA-TNC attribute types).
此字段定义属性值字段中包含的属性类型。该字段由PA-TNC属性供应商ID字段限定，因此特定PA-TNC属性类型值（例如327）具有完全不同的含义，具体取决于PA-TNC属性供应商ID字段中的值。姿态采集器和姿态验证器不得要求支持特定于供应商的PA-TNC属性类型，并且必须与其他方进行互操作，尽管所支持的特定于供应商的PA-TNC属性类型集存在任何差异（尽管它们可能允许管理员将其配置为需要特定PA-TNC属性类型的支持）。
If the PA-TNC Attribute Vendor ID field has the value zero (0), then the PA-TNC Attribute Type field contains an IETF Standard PA-TNC Attribute Type, as listed in the IANA registry. IANA maintains a registry of PA-TNC Attribute Types. Entries in this registry are added by Expert Review with Specification Required, following the guidelines in section 7. Section 4.2 of this specification defines the initial set of IETF Standard PA-TNC Attribute Types.
如果PA-TNC属性供应商ID字段的值为零（0），则PA-TNC属性类型字段包含IETF标准PA-TNC属性类型，如IANA注册表中所列。IANA维护PA-TNC属性类型的注册表。根据第7节中的指南，通过专家评审添加此注册表中的条目，并提供所需的规范。本规范第4.2节定义了IETF标准PA-TNC属性类型的初始集。
The PA-TNC Attribute Type 0xffffffff is reserved. Posture Collectors and Posture Validators MUST NOT send PA-TNC messages in which the PA-TNC Attribute Type has this reserved value (0xffffffff). If a Posture Collector or Posture Validator receives a message in which the PA-TNC Attribute Type has this reserved value (0xffffffff), it SHOULD respond with an Invalid Parameter error code in a PA-TNC Error attribute.
PA-TNC属性类型0xffffffff是保留的。姿势收集器和姿势验证器不得发送PA-TNC属性类型具有此保留值（0xFFFFFF）的PA-TNC消息。如果姿态采集器或姿态验证器接收到PA-TNC属性类型具有此保留值（0xFFFFFF）的消息，则它应以PA-TNC错误属性中的无效参数错误代码进行响应。
PA-TNC Attribute Length
PA-TNC属性长度
This field contains the length in octets of the entire PA-TNC attribute including the PA-TNC Attribute Header (the fields Flags, PA-TNC Attribute Vendor ID, PA-TNC Attribute Type, and PA-TNC Attribute Length). Therefore, this value MUST always be at least 12. Any Posture Collector or Posture Validator that receives a message with a PA-TNC Attribute Length field whose value is less than 12 SHOULD respond with an Invalid Parameter PA-TNC error code. Similarly, if a Posture Collector or Posture Validator receives a PA-TNC message for an Attribute Type that has a well-known Attribute Value length (e.g., fixed-length attribute value) and the Attribute Length indicates a different value (greater or less than the expected value), the recipient SHOULD respond with an Invalid Parameter PA-TNC error code.
此字段包含整个PA-TNC属性（包括PA-TNC属性头）的长度（以八位字节为单位）（字段标志、PA-TNC属性供应商ID、PA-TNC属性类型和PA-TNC属性长度）。因此，该值必须始终至少为12。任何姿态采集器或姿态验证器如果接收到带有值小于12的PA-TNC属性长度字段的消息，则应使用无效参数PA-TNC错误代码进行响应。类似地，如果姿势收集器或姿势验证器接收到具有已知属性值长度（例如，固定长度属性值）的属性类型的PA-TNC消息，并且属性长度指示不同的值（大于或小于预期值），收件人应使用无效参数PA-TNC错误代码进行响应。
Implementations that do not support the specified PA-TNC Attribute Type can use this length to skip over this attribute to the next attribute. Note that while this field is 4 octets the maximum usable attribute length is less than 2^32-1 due to limitations of the underlying protocol stack. Specifically, PB-TNC TLV header's Batch Length field is also 32 bits in length. Therefore, the maximum batch that PB-TNC can carry is 2^32-1, so the largest PA-TNC message carried by PB-TNC must be less than 2^32-1 - size of the PB-TNC header (see section 4.1 of PB-TNC for more details).
不支持指定PA-TNC属性类型的实现可以使用此长度将此属性跳过到下一个属性。请注意，虽然此字段为4个八位字节，但由于底层协议堆栈的限制，最大可用属性长度小于2^32-1。具体而言，PB-TNC TLV标头的批处理长度字段的长度也是32位。因此，PB-TNC可以承载的最大批次为2^32-1，因此PB-TNC承载的最大PA-TNC消息必须小于2^32-1-PB-TNC头的大小（有关详细信息，请参阅PB-TNC第4.1节）。
Attribute Value
属性值
This field varies depending on the particular type of attribute being expressed. The contents of this field for each of the IETF Standard PA-TNC Attribute Types are defined in section 4.2.
此字段因所表达的特定属性类型而异。第4.2节定义了IETF标准PA-TNC属性类型的该字段内容。
This section defines an initial set of IETF Standard PA-TNC Attribute Types. These Attribute Types MUST always be used with a PA-TNC Vendor ID of zero (0). If these PA-TNC Attribute Type values are used with a different PA-TNC Vendor ID, they have a completely different meaning that is not defined in this specification.
本节定义了IETF标准PA-TNC属性类型的初始集合。这些属性类型必须始终与零（0）的PA-TNC供应商ID一起使用。如果这些PA-TNC属性类型值与不同的PA-TNC供应商ID一起使用，则它们具有本规范中未定义的完全不同的含义。
The following table briefly describes each attribute and defines the numeric value to be used in the PA-TNC Attribute Type field of the PA-TNC Attribute Header. Later subsections provide detailed specifications for each PA-TNC Attribute Value.
下表简要介绍了每个属性，并定义了要在PA-TNC属性标题的PA-TNC属性类型字段中使用的数值。后面的小节提供了每个PA-TNC属性值的详细规范。
Number Integer Description
------ ------- -----------
0 Testing Reserved for use in
specification examples,
experimentation, and testing.
Number Integer Description
------ ------- -----------
0 Testing Reserved for use in
specification examples,
experimentation, and testing.
1 Attribute Request Contains a list of attribute type values defining the attributes desired from the Posture Collectors.
1属性请求包含属性类型值的列表，这些值定义了姿势采集器所需的属性。
2 Product Information Manufacturer and product information for the component.
2部件的产品信息制造商和产品信息。
3 Numeric Version Numeric version of the component.
3数字版本组件的数字版本。
4 String Version String version of the component.
4字符串版本组件的字符串版本。
5 Operational Status Describes whether the component is running on the endpoint.
5操作状态描述组件是否在端点上运行。
6 Port Filter Lists the set of ports (e.g., TCP port 80 for HTTP) that are allowed or blocked on the endpoint.
6端口筛选器列出端点上允许或阻止的端口集（例如，HTTP的TCP端口80）。
7 Installed Packages List of software packages installed on endpoint that provide the requested component.
7已安装软件包提供所请求组件的端点上安装的软件包列表。
8 PA-TNC Error PA-TNC message or attribute processing error.
8 PA-TNC错误PA-TNC消息或属性处理错误。
9 Assessment Result Result of the assessment performed by a Posture Validator.
9评估结果由姿势验证器执行的评估结果。
10 Remediation Instructions Instructions for remediation generated by a Posture Validator.
10纠正说明姿势验证器生成的纠正说明。
11 Forwarding Enabled Indicates whether packet forwarding has been enabled between different interfaces on the endpoint.
11 Forwarding Enabled表示是否在端点上的不同接口之间启用了数据包转发。
12 Factory Default Password Indicates whether the endpoint Enabled has a factory default password enabled.
12出厂默认密码指示启用的端点是否启用了出厂默认密码。
The following subsections discuss the usage, format, and semantics of the Attribute Value field for each IETF Standard PA-TNC Attribute Type.
以下小节讨论每个IETF标准PA-TNC属性类型的属性值字段的用法、格式和语义。
This PA-TNC Attribute Type allows a Posture Validator to request certain attributes from the registered set of Posture Collectors.
此PA-TNC属性类型允许姿势验证器从已注册的姿势收集器集合请求某些属性。
All Posture Collectors that implement any of the IETF Standard PA Subtypes defined in this specification SHOULD support receiving and processing this attribute type for at least those PA subtypes. This requirement is only a "should" because there are deployment scenarios (e.g., see section A.1) where the Posture Collectors proactively send a set of attributes at the start of an assessment (e.g., based upon local policy), so does not need to support Posture Validator requested attributes. Posture Collectors that receive but do not support the Attribute Request attribute MUST respond with an Attribute Type Not Supported PA-TNC error code. Posture Collectors that receive and process this attribute MAY choose to send all, a subset, or none of the requested attributes but MUST NOT send attributes that were not requested (except Error attributes). All Posture Validators that implement any of the IETF Standard PA Subtypes defined in this specification SHOULD support sending this attribute type for at least those PA subtypes.
实现本规范中定义的任何IETF标准PA子类型的所有姿态采集器应至少支持接收和处理这些PA子类型的属性类型。此要求仅为“应该”，因为存在部署场景（例如，参见第a.1节），其中姿态采集器在评估开始时主动发送一组属性（例如，基于本地策略），因此不需要支持姿态验证器请求的属性。接收但不支持属性请求属性的姿态采集器必须使用不支持的属性类型PA-TNC错误代码进行响应。接收和处理此属性的姿态采集器可以选择发送所有、子集或不发送任何请求的属性，但不得发送未请求的属性（错误属性除外）。实现本规范中定义的任何IETF标准PA子类型的所有姿态验证器应支持至少为这些PA子类型发送此属性类型。
Posture Validators MUST NOT include this attribute type in an Attribute Request attribute. It does not make sense for a Posture Validator to request that a Posture Collector send an Attribute Request attribute.
姿态验证器不得在属性请求属性中包含此属性类型。姿势验证器请求姿势收集器发送属性请求属性是没有意义的。
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 1.
对于此属性类型，PA-TNC属性供应商ID字段必须设置为零（0），PA-TNC属性类型字段必须设置为1。
The following diagram illustrates the format and contents of the Attribute Value field for this attribute type. The text after this diagram describes the fields shown here.
下图说明了此属性类型的属性值字段的格式和内容。此图后面的文本描述了此处显示的字段。
Note that this diagram shows two attribute types. The actual number of attribute types included in an Attribute Request attribute can vary from one to a large number (limited only by the maximum message and length supported by the underlying PT protocol). However, each Attribute Request MUST contain at least one attribute type. Because the length of a PA-TNC Attribute Vendor ID paired with a PA-TNC Attribute Type and a 1-octet Reserved field is always 8 octets, the number of requested attributes can be easily computed using the PA-TNC Attribute Length field by subtracting the number of octets in the PA-TNC Attribute Header and dividing by 8. If the PA-TNC Attribute Length field is invalid, Posture Collectors SHOULD respond with an Invalid Parameter PA-TNC error code.
请注意，此图显示了两种属性类型。属性请求属性中包含的属性类型的实际数量可以从一个到大量不等（仅受底层PT协议支持的最大消息和长度限制）。但是，每个属性请求必须至少包含一种属性类型。由于PA-TNC属性供应商ID与PA-TNC属性类型和1-八位字节保留字段配对的长度始终为8个八位字节，因此可以使用PA-TNC属性长度字段通过减去PA-TNC属性头中的八位字节数并除以8来轻松计算请求的属性数。如果PA-TNC属性长度字段无效，姿态采集器应使用无效参数PA-TNC错误代码进行响应。
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 | PA-TNC Attribute Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | PA-TNC Attribute Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | PA-TNC Attribute Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | PA-TNC Attribute Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
含蓄的
Reserved for future use. This field MUST be set to 0 on transmission and ignored upon reception.
保留供将来使用。此字段在传输时必须设置为0，在接收时忽略。
PA-TNC Attribute Vendor ID
PA-TNC属性供应商ID
This field contains the SMI Private Enterprise Number of the organization that controls the namespace for the following PA-TNC Attribute Type. This field enables IETF Standard PA-TNC Attributes and vendor-defined PA-TNC attributes to be used without potential collisions.
此字段包含控制以下PA-TNC属性类型命名空间的组织的SMI私有企业编号。该字段使IETF标准PA-TNC属性和供应商定义的PA-TNC属性能够在没有潜在冲突的情况下使用。
Any IETF Standard PA-TNC Attribute Types defined in section 4.2 MUST use zero (0) in this field. Vendor-defined attributes MUST use the SMI Private Enterprise Number of the organization that defined the attribute.
第4.2节中定义的任何IETF标准PA-TNC属性类型在此字段中必须使用零（0）。供应商定义的属性必须使用定义该属性的组织的SMI私有企业编号。
PA-TNC Attribute Type
PA-TNC属性类型
The PA-TNC Attribute Type field (together with the PA-TNC Vendor ID field) indicates the specific attribute requested. Some IETF Standard PA-TNC Attribute Types MUST NOT be requested using this field (e.g., requesting a PA-TNC Error attribute). This is explicitly indicated in the description of those PA-TNC Attribute Types. Any Posture Collector or Posture Validator that receives an Attribute Request containing one of the prohibited Attribute Types SHOULD respond with an Invalid Parameter error in a PA-TNC error message.
PA-TNC属性类型字段（与PA-TNC供应商ID字段一起）表示请求的特定属性。不得使用此字段请求某些IETF标准PA-TNC属性类型（例如，请求PA-TNC错误属性）。这些PA-TNC属性类型的描述中明确指出了这一点。任何接收到包含禁止属性类型之一的属性请求的姿态收集器或姿态验证器都应在PA-TNC错误消息中以无效参数错误进行响应。
This PA-TNC Attribute Type contains identifying information about a product that implements the component specified in the PA Subtype field, as described in section 3.5. For example, if the PA Subtype is Anti-Virus, this attribute would contain information identifying an anti-virus product installed on the endpoint.
如第3.5节所述，此PA-TNC属性类型包含有关实现PA子类型字段中指定组件的产品的标识信息。例如，如果PA子类型是防病毒的，则此属性将包含标识端点上安装的防病毒产品的信息。
All Posture Collectors that implement any of the IETF Standard PA Subtypes defined in this specification MUST support sending this attribute type, at least for those PA subtypes. Whether a particular Posture Collector actually sends this attribute type SHOULD still be governed by local privacy and security policies. All Posture Validators that implement any of the IETF Standard PA Subtypes defined in this specification MUST support receiving this attribute type, at least for those PA subtypes. Posture Validators MUST NOT send this attribute type.
实现本规范中定义的任何IETF标准PA子类型的所有姿态采集器必须支持发送此属性类型，至少对于这些PA子类型。特定的姿态收集器是否实际发送此属性类型仍应由本地隐私和安全策略控制。实现本规范中定义的任何IETF标准PA子类型的所有姿态验证器必须支持接收该属性类型，至少对于那些PA子类型。姿态验证器不能发送此属性类型。
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 2. The value in the PA-TNC Attribute Length field will vary, depending on the length of the Product Name field. However, the value in the PA-TNC Attribute Length field MUST be at least 17 because this is the length of the fixed-length fields in the PA-TNC Attribute Header and the fixed-length fields in this attribute type. If the PA-TNC Attribute Length field is less than the size of these fixed-length fields, implementations SHOULD respond with an Invalid Parameter PA-TNC error code.
对于此属性类型，PA-TNC属性供应商ID字段必须设置为零（0），PA-TNC属性类型字段必须设置为2。PA-TNC属性长度字段中的值会有所不同，具体取决于产品名称字段的长度。但是，PA-TNC属性长度字段中的值必须至少为17，因为这是PA-TNC属性头中的固定长度字段和此属性类型中的固定长度字段的长度。如果PA-TNC属性长度字段小于这些固定长度字段的大小，则实现应使用无效参数PA-TNC错误代码进行响应。
This attribute type includes both numeric and textual identifiers for the organization that created the product (the "product creator") and for the product itself. For automated processing, numeric identifiers are superior because they are less ambiguous and more efficient. However, numeric identifiers are only available if the product creator has assigned them. Therefore, a textual identifier is also included. This textual identifier has the additional benefit that it may be easier for humans to read (although this benefit is minimal since the primary purpose of this attribute is automated assessment).
此属性类型包括创建产品的组织（“产品创建者”）和产品本身的数字和文本标识符。对于自动化处理，数字标识符更优越，因为它们不那么模棱两可，效率更高。但是，数字标识符仅在产品创建者已分配时可用。因此，还包括文本标识符。此文本标识符还有一个额外的好处，即人类可能更容易阅读（尽管此好处很小，因为此属性的主要用途是自动评估）。
The following diagram illustrates the format and contents of the Attribute Value field for this attribute type. The text after this diagram describes the fields shown here.
下图说明了此属性类型的属性值字段的格式和内容。此图后面的文本描述了此处显示的字段。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Product Vendor ID | Product ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Product ID | Product Name (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Product Vendor ID | Product ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Product ID | Product Name (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Product Vendor ID
产品供应商ID
This field contains the SMI Private Enterprise Number for the product creator. If the SMI PEN for the product creator is unknown or if the product creator does not have an SMI PEN, the Product Vendor ID field MUST be set to 0 and the identity of the product creator SHOULD be included in the Product Name along with the name of the product.
此字段包含产品创建者的SMI私有企业编号。如果产品创建者的SMI笔未知或产品创建者没有SMI笔，则必须将“产品供应商ID”字段设置为0，并且产品名称中应包含产品创建者的身份以及产品名称。
Product ID
产品ID
This field identifies the product using a numeric identifier assigned by the product creator. If this Product ID value is unknown or if the product creator has not assigned such a value, this field MUST be set to 0. If the Product Vendor ID is 0, this field MUST be set to 0. In any case, the name of the product SHOULD be included in the Product Name field.
此字段使用产品创建者指定的数字标识符标识产品。如果此产品ID值未知或产品创建者未分配此值，则此字段必须设置为0。如果产品供应商ID为0，则此字段必须设置为0。在任何情况下，产品名称都应包含在产品名称字段中。
Note that a particular Product ID value (e.g., 635) will have completely different meanings depending on the Product Vendor ID. Each Product Vendor ID defines a different space of Product ID values. Product creators are encouraged to publish lists of Product ID values for their products.
请注意，特定的产品ID值（例如635）将根据产品供应商ID具有完全不同的含义。每个产品供应商ID定义了不同的产品ID值空间。鼓励产品创建者发布其产品的产品ID值列表。
Product Name
品名
This variable-length field contains a UTF-8 [2] string identifying the product (e.g., "Symantec Norton AntiVirus(TM) 2008") in enough detail to unambiguously distinguish it from other products from the product creator. Products whose creator is known, but does not have a registered SMI Private Enterprise Number, SHOULD be represented using a combination of the creator name and full product name (e.g., "Ubuntu(R) IPtables" for the IPtables firewall in the Ubuntu distribution of Linux). If the product creator's SMI Private Enterprise Number is included in the Product Vendor ID field, the product creator's name may be omitted from this field.
此可变长度字段包含一个UTF-8[2]字符串，该字符串足够详细地标识产品（例如，“Symantec Norton AntiVirus（TM）2008”），以明确区分产品创建者的其他产品。创建者已知但没有注册SMI私有企业编号的产品应使用创建者名称和完整产品名称的组合来表示（例如，Linux Ubuntu发行版中IPtables防火墙的“Ubuntu（R）IPtables”）。如果产品创建者的SMI私有企业编号包含在产品供应商ID字段中，则此字段中可能会省略产品创建者的名称。
The length of this field can be determined by starting with the value in the PA-TNC Attribute Length field in the PA-TNC Attribute Header and subtracting the size of the fixed-length fields in that header (12) and the size of the fixed-length fields in this attribute (5). If the PA-TNC Attribute Length field is less than the size of these fixed-length fields, implementations SHOULD respond with an Invalid Parameter PA-TNC error code.
该字段的长度可以通过从PA-TNC属性头中PA-TNC属性长度字段中的值开始，减去该头（12）中固定长度字段的大小和该属性（5）中固定长度字段的大小来确定。如果PA-TNC属性长度字段小于这些固定长度字段的大小，则实现应使用无效参数PA-TNC错误代码进行响应。
This PA-TNC Attribute Type contains numeric version information for a product on the endpoint that implements the component specified in the PA Subtype field, as described in section 3.5. For example, if the PA Subtype is Operating System, this attribute would contain numeric version information for the operating system installed on the endpoint. The version information in this attribute is associated with a particular product, so Posture Validators are expected to also possess the corresponding Product Information attribute when interpreting this attribute.
此PA-TNC属性类型包含实现PA子类型字段中指定组件的端点上产品的数字版本信息，如第3.5节所述。例如，如果PA子类型是Operating System，则此属性将包含端点上安装的操作系统的数字版本信息。此属性中的版本信息与特定产品相关联，因此在解释此属性时，姿态验证器也应具有相应的产品信息属性。
All Posture Collectors that implement the IETF Standard PA Subtype for Operating System SHOULD support sending this attribute type, at least for the Operating System PA subtype. Other Posture Collectors MAY support sending this attribute type. Whether a particular Posture Collector actually sends this attribute type SHOULD still be governed by local privacy and security policies. All Posture Validators that implement the IETF Standard PA Subtype for Operating System SHOULD support receiving this attribute type, at least for the Operating System PA subtype. Other Posture Validators MAY support receiving this attribute type. A Posture Validator that does not support receiving this attribute type SHOULD simply ignore attributes with this type. Posture Validators MUST NOT send this attribute type.
为操作系统实现IETF标准PA子类型的所有姿态采集器都应支持发送此属性类型，至少对于操作系统PA子类型。其他姿态采集器可能支持发送此属性类型。特定的姿态收集器是否实际发送此属性类型仍应由本地隐私和安全策略控制。为操作系统实现IETF标准PA子类型的所有姿态验证器都应支持接收此属性类型，至少对于操作系统PA子类型。其他姿势验证器可能支持接收此属性类型。不支持接收此属性类型的姿势验证器应忽略具有此类型的属性。姿态验证器不能发送此属性类型。
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 3. The value in the PA-TNC Attribute Length field MUST be 28. If the PA-TNC Attribute Length field is less than the size of these fixed-length fields, implementations SHOULD respond with an Invalid Parameter PA-TNC error code.
对于此属性类型，PA-TNC属性供应商ID字段必须设置为零（0），PA-TNC属性类型字段必须设置为3。PA-TNC属性长度字段中的值必须为28。如果PA-TNC属性长度字段小于这些固定长度字段的大小，则实现应使用无效参数PA-TNC错误代码进行响应。
This attribute type includes numeric values for the product version information, enabling Posture Validators to do comparative operations on the version. Some Posture Collectors may not be able to determine some or all of this information for a product. However, this attribute can be especially useful for describing the version of the operating system, where numeric version numbers are generally available.
此属性类型包括产品版本信息的数值，使姿态验证器能够对版本执行比较操作。某些姿势收集器可能无法确定产品的部分或全部信息。但是，此属性对于描述操作系统的版本特别有用，因为通常可以使用数字版本号。
The following diagram illustrates the format and contents of the Attribute Value field for this attribute type. The text after this diagram describes the fields shown here.
下图说明了此属性类型的属性值字段的格式和内容。此图后面的文本描述了此处显示的字段。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Major Version Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minor Version Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Build Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Pack Major | Service Pack Minor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Major Version Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minor Version Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Build Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Pack Major | Service Pack Minor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Major Version Number
主要版本号
This field contains the major version number for the product, if applicable. If unused or unknown, this field SHOULD be set to 0.
此字段包含产品的主要版本号（如果适用）。如果未使用或未知，此字段应设置为0。
Minor Version Number
次要版本号
This field contains the minor version number for the product, if applicable. If unused or unknown, this field SHOULD be set to 0.
此字段包含产品的次要版本号（如果适用）。如果未使用或未知，此字段应设置为0。
Build Number
建筑编号
This field contains the build number for the product, if applicable. This may provide more granularity than the minor version number, as many builds may occur leading up to an official release, and all these builds may share a single major and minor version number. If unused or unknown, this field SHOULD be set to 0.
此字段包含产品的内部版本号（如果适用）。这可能比次要版本号提供更多的粒度，因为在正式发布之前可能会出现许多版本，并且所有这些版本可能共享一个主要和次要版本号。如果未使用或未知，此字段应设置为0。
Service Pack Major
服务包专业
This field contains the major version number of the service pack for the product, if applicable. If unused or unknown, this field SHOULD be set to 0.
此字段包含产品service pack的主要版本号（如果适用）。如果未使用或未知，此字段应设置为0。
Service Pack Minor
小号服务包
This field contains the minor version number of the service pack for the product, if applicable. If unused or unknown, this field SHOULD be set to 0.
此字段包含产品service pack的次要版本号（如果适用）。如果未使用或未知，此字段应设置为0。
This PA-TNC Attribute Type contains string version information for a product on the endpoint that implements the component specified in the PA Subtype field, as described in section 3.5. For example, if the PA Subtype is Firewall, this attribute would contain string version information for a host-based firewall product installed on the endpoint (if any). The version information in this attribute is associated with a particular product, so Posture Validators are expected to also possess the corresponding Product Information attribute when interpreting this attribute.
此PA-TNC属性类型包含实现PA子类型字段中指定组件的端点上产品的字符串版本信息，如第3.5节所述。例如，如果PA子类型是Firewall，则此属性将包含端点上安装的基于主机的防火墙产品（如果有）的字符串版本信息。此属性中的版本信息与特定产品相关联，因此在解释此属性时，姿态验证器也应具有相应的产品信息属性。
All Posture Collectors that implement any of the IETF Standard PA Subtypes defined in this document MUST support sending this attribute type, at least for those PA subtypes. Other Posture Collectors MAY support sending this attribute type. Whether a particular Posture Collector actually sends this attribute type SHOULD still be governed by local privacy and security policies. All Posture Validators that implement any of the IETF Standard PA Subtypes defined in this document MUST support receiving this attribute type, at least for those PA subtypes. Other Posture Validators MAY support receiving this attribute type. Posture Validators MUST NOT send this attribute type.
实现本文档中定义的任何IETF标准PA子类型的所有姿态采集器必须支持发送此属性类型，至少对于这些PA子类型。其他姿态采集器可能支持发送此属性类型。特定的姿态收集器是否实际发送此属性类型仍应由本地隐私和安全策略控制。实现本文档中定义的任何IETF标准PA子类型的所有姿态验证器必须支持接收该属性类型，至少对于这些PA子类型是这样。其他姿势验证器可能支持接收此属性类型。姿态验证器不能发送此属性类型。
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 4. The value in the PA-TNC Attribute Length field will vary, depending
对于此属性类型，PA-TNC属性供应商ID字段必须设置为零（0），PA-TNC属性类型字段必须设置为4。PA-TNC属性长度字段中的值将根据具体情况而变化
on the length of the Component Version Number, Internal Build Number, and Configuration Version Number fields. However, the value in the PA-TNC Attribute Length field MUST be at least 15 because this is the length of the fixed-length fields in the PA-TNC Attribute Header and the fixed-length fields in this attribute type. If the PA-TNC Attribute Length field is less than the size of these fixed-length fields or does not match the length indicated by the sum of the fixed-length and variable-length fields, implementations SHOULD respond with an Invalid Parameter PA-TNC error code.
组件版本号、内部版本号和配置版本号字段的长度。但是，PA-TNC属性长度字段中的值必须至少为15，因为这是PA-TNC属性头中的固定长度字段和此属性类型中的固定长度字段的长度。如果PA-TNC属性长度字段小于这些固定长度字段的大小，或者与固定长度字段和可变长度字段之和指示的长度不匹配，则实现应使用无效参数PA-TNC错误代码进行响应。
The following diagram illustrates the format and contents of the Attribute Value field for this attribute type. The text after this diagram describes the fields shown here.
下图说明了此属性类型的属性值字段的格式和内容。此图后面的文本描述了此处显示的字段。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Len | Product Version Number (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Build Num Len | Internal Build Number (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Config. Len | Configuration Version Number (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Len | Product Version Number (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Build Num Len | Internal Build Number (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Config. Len | Configuration Version Number (Variable Length)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version Len
版本Len
This field defines the number of octets in the Product Version Number field. If the product version number is unavailable or unknown, this field MUST be set to 0 and the Product Version Number field will be zero length (effectively not present).
此字段定义产品版本号字段中的八位字节数。如果产品版本号不可用或未知，则此字段必须设置为0，并且产品版本号字段的长度为零（实际上不存在）。
Product Version Number
产品版本号
This field contains a UTF-8 string identifying the version of the component (e.g., "1.12.23.114"). This field MUST be sized to fit the version string and MUST NOT include extra octets for padding or NUL character termination.
此字段包含标识组件版本的UTF-8字符串（例如，“1.12.23.114”）。此字段的大小必须适合版本字符串，并且不得包含用于填充或NUL字符终止的额外八位字节。
Various products use a wide range of different formats and semantics for version strings. Some use alphabetic characters, white space, and punctuation. Some consider version "1.21" to be later than version "1.3" and some earlier. Therefore, the syntax and semantics of this string are not defined.
各种产品对版本字符串使用各种不同的格式和语义。有些使用字母、空格和标点符号。有些人认为版本“1.21”要晚于版本“1.3”和一些较早的版本。因此，未定义此字符串的语法和语义。
Build Num Len
构建数Len
This field defines the number of octets in the Internal Build Number field. For products where the internal build number is unavailable or unknown, this field MUST be set to 0 and the Internal Build Number field will be zero length (effectively not present).
此字段定义内部内部版本号字段中的八位字节数。对于内部版本号不可用或未知的产品，此字段必须设置为0，并且内部版本号字段的长度为零（实际上不存在）。
Internal Build Number
内部版本号
This field contains a UTF-8 string identifying the engineering build number of the product. This field MUST be sized to fit the build number string and MUST NOT include extra octets for padding or NUL character termination. The syntax and semantics of this string are not defined.
此字段包含一个UTF-8字符串，用于标识产品的工程版本号。此字段的大小必须适合内部版本号字符串，并且不得包含用于填充或NUL字符终止的额外八位字节。未定义此字符串的语法和语义。
Config. Len
配置。伦恩
This field defines the number of octets in the Configuration Version Number field. If the configuration version number is unavailable or unknown, this field MUST be set to 0 and the Configuration Version Number field will be zero length (effectively not present).
此字段定义配置版本号字段中的八位字节数。如果配置版本号不可用或未知，则此字段必须设置为0，并且配置版本号字段的长度为零（实际上不存在）。
Configuration Version Number
配置版本号
This field contains a UTF-8 string identifying the version of the configuration used by the component. This version SHOULD represent the overall configuration version even if several configuration policy files or settings are used. Posture Collectors MAY include multiple version numbers in this single string if a single version is not practical. This field MUST be sized to fit the version string and MUST NOT include extra octets for padding or NUL character termination.
此字段包含一个UTF-8字符串，标识组件使用的配置版本。即使使用了多个配置策略文件或设置，此版本也应表示总体配置版本。如果单个版本不实用，姿态收集器可能会在单个字符串中包含多个版本号。此字段的大小必须适合版本字符串，并且不得包含用于填充或NUL字符终止的额外八位字节。
Various products use a wide range of different formats for version strings. Some use alphabetic characters, white space, and punctuation. Some consider version "1.21" to be later than version "1.3" and some earlier. In addition, some Posture Collectors may place multiple configuration version numbers in this single string. Therefore, the syntax and semantics of this string are not defined.
各种产品对版本字符串使用各种不同的格式。有些使用字母、空格和标点符号。有些人认为版本“1.21”要晚于版本“1.3”和一些较早的版本。此外，一些姿态采集器可能会在此单个字符串中放置多个配置版本号。因此，未定义此字符串的语法和语义。
This PA-TNC Attribute Type describes the operational status of a product that can implement the component specified in the PA Subtype field, as described in section 3.5. For example, if the PA Subtype is
如第3.5节所述，该PA-TNC属性类型描述了可实现PA子类型字段中指定组件的产品的运行状态。例如，如果PA子类型为
Anti-Spyware, this attribute would contain information about the operational status of a host-based anti-spyware product that may or may not be installed on the endpoint.
反间谍软件，此属性将包含有关基于主机的反间谍软件产品的操作状态的信息，该产品可能安装在端点上，也可能未安装在端点上。
Posture Collectors that implement the IETF Standard PA Subtype for Operating System or VPN MAY support sending this attribute type for those PA subtypes. Posture Collectors that implement other IETF Standard PA Subtypes defined in this specification SHOULD support sending this attribute type for those PA subtypes. Other Posture Collectors MAY support sending this attribute type. Whether a particular Posture Collector actually sends this attribute type SHOULD still be governed by local privacy and security policies. Posture Validators that implement the IETF Standard PA Subtype for Operating System or VPN MAY support receiving this attribute type, at least for those PA subtypes. Posture Validators that implement other IETF Standard PA Subtypes defined in this specification SHOULD support receiving this attribute type, at least for those PA subtypes. Other Posture Validators MAY support receiving this attribute type. A Posture Validator that does not support receiving this attribute type SHOULD simply ignore attributes with this type. Posture Validators MUST NOT send this attribute type.
为操作系统或VPN实现IETF标准PA子类型的姿态采集器可能支持为这些PA子类型发送此属性类型。实现本规范中定义的其他IETF标准PA子类型的姿态采集器应支持为这些PA子类型发送此属性类型。其他姿态采集器可能支持发送此属性类型。特定的姿态收集器是否实际发送此属性类型仍应由本地隐私和安全策略控制。为操作系统或VPN实现IETF标准PA子类型的姿态验证器可支持接收此属性类型，至少对于这些PA子类型。实现本规范中定义的其他IETF标准PA子类型的姿态验证器应支持接收该属性类型，至少对于那些PA子类型。其他姿势验证器可能支持接收此属性类型。不支持接收此属性类型的姿势验证器应忽略具有此类型的属性。姿态验证器不能发送此属性类型。
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 5. The value in the PA-TNC Attribute Length field MUST be 36. If the PA-TNC Attribute Length field does not have this value, implementations SHOULD respond with an Invalid Parameter PA-TNC error code.
对于此属性类型，PA-TNC属性供应商ID字段必须设置为零（0），PA-TNC属性类型字段必须设置为5。PA-TNC属性长度字段中的值必须为36。如果PA-TNC属性长度字段没有此值，则实现应使用无效参数PA-TNC错误代码进行响应。
The following diagram illustrates the format and contents of the Attribute Value field for this attribute type. The text after this diagram describes the fields shown here.
下图说明了此属性类型的属性值字段的格式和内容。此图后面的文本描述了此处显示的字段。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Result | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Use |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Use (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Use (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Use (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Use (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Result | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Use |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Use (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Use (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Use (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Use (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Status
地位
This field gives the operational status of the product. The following table lists the values currently defined for this field.
此字段提供产品的运行状态。下表列出了当前为此字段定义的值。
Value Description
----- -----------
0 Unknown or other
1 Not installed
2 Installed but not operational
3 Operational
Value Description
----- -----------
0 Unknown or other
1 Not installed
2 Installed but not operational
3 Operational
If a Posture Validator receives a value for this field that it does not recognize, it SHOULD treat this value as equivalent to the value 0.
如果姿势验证器接收到该字段的值而无法识别，则应将该值视为等同于值0。
Result
后果
This field contains the result of the last use of the product. The following table lists the values currently defined for this field.
此字段包含上次使用产品的结果。下表列出了当前为此字段定义的值。
Value Description
----- -----------
0 Unknown or other
1 Successful use with no errors detected
2 Successful use with one or more errors detected
3 Unsuccessful use (e.g., aborted)
Value Description
----- -----------
0 Unknown or other
1 Successful use with no errors detected
2 Successful use with one or more errors detected
3 Unsuccessful use (e.g., aborted)
Posture Collectors SHOULD set this field to 0 if the Status field contains a value of 1 (Not installed) or 2 (Installed but not operational). If a Posture Validator receives a value for this field that it does not recognize, it SHOULD treat this value as equivalent to the value 0.
如果状态字段包含值1（未安装）或2（已安装但未运行），则姿态采集器应将此字段设置为0。如果姿势验证器接收到该字段的值而无法识别，则应将该值视为等同于值0。
Reserved
含蓄的
This field is reserved for future use. The field MUST be set to 0 on transmission and ignored upon reception.
此字段保留供将来使用。该字段在传输时必须设置为0，在接收时必须忽略。
Last Use
最后使用
This field contains the date and time of the last use of the component. The Last Use date and time MUST be represented as an RFC 3339 [4] compliant ASCII string in Coordinated Universal Time (UTC) time with the additional restrictions that the 't' delimiter and the 'z' suffix MUST be capitalized and fractional seconds (time-secfrac) MUST NOT be included.
此字段包含上次使用组件的日期和时间。最后一次使用日期和时间必须以协调世界时（UTC）时间表示为符合RFC 3339[4]的ASCII字符串，附加限制是“t”分隔符和“z”后缀必须大写，并且不得包含小数秒（time secfrac）。
This field conforms to the date-time ABNF production from section 5.6 of RFC 3339 with the above restrictions. Leap seconds are permitted and Posture Validators MUST support them.
该字段符合RFC 3339第5.6节规定的ABNF生产日期和时间，并有上述限制。允许跳跃秒，姿势验证器必须支持跳跃秒。
The last use string MUST NOT be NUL terminated or padded in any way. If the last use time is not known, not applicable, or cannot be represented in this format, the Posture Collector MUST set this field to the value "0000-00-00T00:00:00Z" (allowing this field to be fixed length). Note that this particular reserved value is NOT a valid RFC 3339 date and time and MUST NOT be used for any other purpose in this field.
最后一次使用字符串不得以任何方式以NUL结尾或填充。如果上次使用时间未知、不适用或无法用此格式表示，姿势采集器必须将此字段设置为值“0000-00-00T00:00:00Z”（允许此字段为固定长度）。请注意，此特定保留值不是有效的RFC 3339日期和时间，不得用于此字段中的任何其他用途。
This encoding produces a string that is easy to read, parse, and interpret. The format (more precisely defined in RFC 3339) is YYYY-MM-DDTHH:MM:SSZ, resulting in one and only one representation for each second in UTC time from year 0000 to year 9999. For example, 9:05:00AM EST (GMT-0500) on January 19, 1995 can be represented as "1995-01-19T14:05:00Z". The length of this field is always 20 octets.
这种编码产生易于读取、解析和解释的字符串。格式（在RFC 3339中更精确地定义）为YYYY-MM-DDTHH:MM:SSZ，因此在UTC时间0000年到9999年之间，每秒只能有一个表示。例如，1995年1月19日美国东部时间上午9:05:00（GMT-0500）可以表示为“1995-01-19T14:05:00Z”。此字段的长度始终为20个八位字节。
This PA-TNC Attribute Type provides the list of port numbers and associated protocols (e.g., TCP and UDP) that are currently blocked or allowed by a host-based firewall on the endpoint.
此PA-TNC属性类型提供当前由端点上基于主机的防火墙阻止或允许的端口号和相关协议（例如TCP和UDP）的列表。
Posture Collectors that implement the IETF Standard PA Subtype for Firewall or VPN SHOULD support sending this attribute type for those PA subtypes. Posture Collectors that implement other IETF Standard PA Subtypes defined in this specification MUST NOT support sending this attribute type for those PA subtypes. Other Posture Collectors MAY support sending this attribute type, if it is appropriate to their PA subtype. Whether a particular Posture Collector actually sends this attribute type SHOULD still be governed by local privacy and security policies. Posture Validators that implement the IETF Standard PA Subtype for Firewall or VPN SHOULD support receiving this attribute type, at least for those PA subtypes. Posture Validators that implement other IETF Standard PA Subtypes defined in this specification MUST NOT support receiving this attribute type for those PA subtypes. Other Posture Validators MAY support receiving this attribute type. A Posture Validator that does not support receiving this attribute type SHOULD simply ignore attributes with this type. Posture Validators MUST NOT send this attribute type.
为防火墙或VPN实现IETF标准PA子类型的姿态采集器应支持为这些PA子类型发送此属性类型。实现本规范中定义的其他IETF标准PA子类型的姿态采集器不得支持为这些PA子类型发送此属性类型。其他姿态采集器可能支持发送此属性类型（如果适合其PA子类型）。特定的姿态收集器是否实际发送此属性类型仍应由本地隐私和安全策略控制。为防火墙或VPN实现IETF标准PA子类型的姿态验证器应支持接收此属性类型，至少对于这些PA子类型。实现本规范中定义的其他IETF标准PA子类型的姿态验证器不得支持接收这些PA子类型的该属性类型。其他姿势验证器可能支持接收此属性类型。不支持接收此属性类型的姿势验证器应忽略具有此类型的属性。姿态验证器不能发送此属性类型。
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 6.
对于此属性类型，PA-TNC属性供应商ID字段必须设置为零（0），PA-TNC属性类型字段必须设置为6。
The following diagram illustrates the format and contents of the Attribute Value field for this attribute type. The text after this diagram describes the fields shown here.
下图说明了此属性类型的属性值字段的格式和内容。此图后面的文本描述了此处显示的字段。
Note that this diagram shows two Protocol/Port Number pairs. The actual number of Protocol/Port Number pairs included in a Port Filter attribute can vary from one to a large number (limited only by the maximum message and length supported by the underlying PT protocol). However, each Port Filter attribute MUST contain at least one Protocol/Port Number pair. Because the length of a Protocol/Port Number pair with the Reserved field and B flag is always 4 octets, the number of Protocol/Port Number pairs can be easily computed using the PA-TNC Attribute Length field by subtracting the number of octets in the PA-TNC Attribute Header and dividing by 4. If the PA-TNC Attribute Length field is invalid, Posture Validators SHOULD respond with an Invalid Parameter PA-TNC error code.
请注意，此图显示了两个协议/端口号对。端口筛选器属性中包含的协议/端口号对的实际数量可以从一个到一个较大的数字不等（仅受底层PT协议支持的最大消息和长度限制）。但是，每个端口筛选器属性必须至少包含一个协议/端口号对。由于带有保留字段和B标志的协议/端口号对的长度始终为4个八位字节，因此可以使用PA-TNC属性长度字段通过减去PA-TNC属性头中的八位字节数并除以4来轻松计算协议/端口号对的数量。如果PA-TNC属性长度字段无效，姿势验证器应使用无效参数PA-TNC错误代码进行响应。
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 |B| Protocol | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |B| Protocol | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |B| Protocol | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |B| Protocol | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
含蓄的
This field is reserved for future use. It MUST be set to 0 on transmission and ignored upon reception.
此字段保留供将来使用。传输时必须将其设置为0，接收时忽略。
B Flag (Blocked or Allowed Port)
B标志（阻塞或允许的端口）
This single-bit field indicates whether the following port is blocked or allowed. This bit MUST be set to 1 if the protocol and port combination is blocked. Otherwise, this field MUST be set to 0. This field was provided to allow for more abbreviated reporting of the port filtering policy (e.g., when all ports are blocked except a few, the Posture Collector can just list the few that are allowed).
此单位字段指示是否阻止或允许以下端口。如果协议和端口组合被阻止，则此位必须设置为1。否则，此字段必须设置为0。提供此字段是为了更简短地报告端口筛选策略（例如，当除少数端口外的所有端口都被阻止时，姿态收集器可以只列出允许的少数端口）。
Posture Collectors MUST NOT provide a mixed list of blocked and non-blocked ports for a particular protocol. To be more precise, a Posture Collector MUST NOT include two Protocol/Port Number pairs in a single Port Filter attribute where the protocol number is the same but the B flag is different. Also, Posture Collectors MUST NOT list the same Protocol and Port Number combination twice in a Port List attribute.
姿态采集器不得为特定协议提供阻塞端口和非阻塞端口的混合列表。更准确地说，如果协议号相同但B标志不同，则姿态采集器不得在单个端口筛选器属性中包含两个协议/端口号对。此外，姿态采集器不得在端口列表属性中两次列出相同的协议和端口号组合。
Posture Collectors MAY list all blocked ports for one protocol and all allowed ports for a different protocol in a single Port List attribute, using the B flag to indicate whether each entry is blocked. For example, a Posture Collector might list all the blocked TCP ports but only list the allowed UDP ports. However, it MUST NOT list some blocked TCP ports and some other allowed TCP ports.
姿态采集器可以在单个端口列表属性中列出一个协议的所有被阻止端口和不同协议的所有允许端口，使用B标志指示每个条目是否被阻止。例如，姿态收集器可能会列出所有被阻止的TCP端口，但只列出允许的UDP端口。但是，它不能列出一些被阻止的TCP端口和一些其他允许的TCP端口。
Protocol
协议
This field contains the transport protocol number (e.g., tcp is 6) being blocked or allowed. The values used in this field are the same ones used in the IPv4 Protocol and IPv6 Next Header fields. The IANA already maintains the Assigned Internet Protocol Numbers registry of these values for use in this field.
此字段包含被阻止或允许的传输协议号（例如tcp为6）。此字段中使用的值与IPv4协议和IPv6下一个标头字段中使用的值相同。IANA已经维护了这些值的指定Internet协议号注册表，以便在此字段中使用。
Port Number
端口号
This field contains the transport protocol (e.g., tcp) port number being blocked or allowed. The values used in this field are specific to the protocol identified by the Protocol field. The IANA maintains registries for well-known and user-requested TCP and UDP port numbers for use in this field.
此字段包含被阻止或允许的传输协议（如tcp）端口号。此字段中使用的值特定于协议字段标识的协议。IANA维护用于此字段的已知和用户请求的TCP和UDP端口号的注册表。
This PA-TNC Attribute Type contains a list of the installed packages that comprise a product on the endpoint that implements the component specified in the PA Subtype field, as described in section 3.5. This allows a Posture Validator to check which packages are installed for a particular product and which versions of those packages are installed.
如第3.5节所述，此PA-TNC属性类型包含已安装软件包的列表，这些软件包包括实现PA子类型字段中指定组件的端点上的产品。这允许姿态验证器检查为特定产品安装了哪些软件包以及安装了这些软件包的哪些版本。
Posture Collectors that implement any of the IETF Standard PA Subtypes defined in this document SHOULD support sending this attribute type for those PA subtypes. Other Posture Collectors MAY support sending this attribute type, if it is appropriate to their PA subtype. Whether a particular Posture Collector actually sends this attribute type SHOULD still be governed by local privacy and security policies. Posture Validators that implement any of the IETF Standard PA Subtypes defined in this document SHOULD support receiving this attribute type, at least for those PA subtypes. Other Posture Validators MAY support receiving this attribute type. A Posture Validator that does not support receiving this attribute type SHOULD simply ignore attributes with this type. Posture Validators MUST NOT send this attribute type.
实现本文档中定义的任何IETF标准PA子类型的姿态采集器应支持为这些PA子类型发送此属性类型。其他姿态采集器可能支持发送此属性类型（如果适合其PA子类型）。特定的姿态收集器是否实际发送此属性类型仍应由本地隐私和安全策略控制。实现本文档中定义的任何IETF标准PA子类型的姿态验证器应支持接收此属性类型，至少对于这些PA子类型。其他姿势验证器可能支持接收此属性类型。不支持接收此属性类型的姿势验证器应忽略具有此类型的属性。姿态验证器不能发送此属性类型。
This attribute type can be quite long, especially for the Operating System PA subtype. This can cause problems, especially with 802.1X and other limited transport protocols. Therefore, Posture Collectors SHOULD NOT send this attribute unless specifically requested to do so using the Attribute Request attribute or otherwise configured to do so. Also, Posture Validators SHOULD NOT request this attribute unless the transport protocol in use can support the large amount of data that may be sent in response.
此属性类型可能相当长，特别是对于操作系统PA子类型。这可能会导致问题，尤其是802.1X和其他有限的传输协议。因此，姿态采集器不应发送此属性，除非使用属性请求属性明确请求发送此属性，或者配置为发送此属性。此外，姿势验证器不应请求此属性，除非所使用的传输协议能够支持响应中可能发送的大量数据。
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 7. The value in the PA-TNC Attribute Length field will vary, depending on the number of packages and the length of the Package Name and Package Version Number fields for those packages. However, the value in the PA-TNC Attribute Length field MUST be at least 16 because this is the length of the fixed-length fields in the PA-TNC Attribute Header and the fixed-length fields in this attribute type. If the PA-TNC Attribute Length field is less than the size of these fixed-length fields or does not match the length indicated by the sum of the fixed-length and variable-length fields, implementations SHOULD respond with an Invalid Parameter PA-TNC error code.
对于此属性类型，PA-TNC属性供应商ID字段必须设置为零（0），PA-TNC属性类型字段必须设置为7。PA-TNC属性长度字段中的值将有所不同，具体取决于包的数量以及这些包的包名称和包版本号字段的长度。但是，PA-TNC属性长度字段中的值必须至少为16，因为这是PA-TNC属性头中的固定长度字段和此属性类型中的固定长度字段的长度。如果PA-TNC属性长度字段小于这些固定长度字段的大小，或者与固定长度字段和可变长度字段之和指示的长度不匹配，则实现应使用无效参数PA-TNC错误代码进行响应。
The following diagram illustrates the format and contents of the Attribute Value field for this attribute type. The text after this diagram describes the fields shown here.
下图说明了此属性类型的属性值字段的格式和内容。此图后面的文本描述了此处显示的字段。
Note that this diagram shows an attribute containing information on one package. The actual number of package descriptions included in an Installed Packages attribute is indicated by the Package Count field. This value may vary from zero to a large number (up to 65535, if the underlying PT protocol can support that many). If this number is not sufficient, specialized patch management software should be employed that can simply report compliance with a pre-established patch policy.
请注意，此图显示了包含一个包的信息的属性。“已安装软件包”属性中包含的软件包描述的实际数量由“软件包计数”字段指示。该值可能从零到一个较大的数字不等（如果基础PT协议可以支持65535）。如果这个数字不够，应该使用专门的补丁管理软件，它可以简单地报告是否符合预先建立的补丁策略。
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 | Package Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pkg Name Len | Package Name (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Len | Package Version Number (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 | Package Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pkg Name Len | Package Name (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Len | Package Version Number (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
含蓄的
This field is reserved for future use. The field MUST be set to 0 on transmission and ignored upon reception.
此字段保留供将来使用。该字段在传输时必须设置为0，在接收时必须忽略。
Package Count
包数
This field is an unsigned 16-bit integer that indicates the number of packages listed in this attribute. For each package so indicated, a Pkg Name Len, Package Name, Version Len, and Package Version Number field is included in the attribute.
此字段是一个无符号16位整数，表示此属性中列出的包数。对于如此指示的每个包，属性中包括一个Pkg Name Len、package Name、Version Len和package Version Number字段。
Pkg Name Len
包装名称Len
This field is an unsigned 8-bit integer that indicates the length of the Package Name field in octets. This field may be zero if a Package Name is not available.
此字段是一个无符号8位整数，以八位字节表示包名字段的长度。如果包名称不可用，则此字段可能为零。
Package Name
包名
This field contains the name of the package associated with the product. This field is a UTF-8 encoded character string whose octet length is given by the Pkg Name Len field. This field MUST NOT include extra octets for padding or NUL character termination. The syntax and semantics of this name are not specified in this document, since they may vary across products and/or operating systems. Posture Collectors MAY list two packages with the same name in a single Installed Packages attribute. The meaning of doing so is not defined here.
此字段包含与产品关联的包的名称。此字段是UTF-8编码字符串，其八位字节长度由Pkg Name Len字段给出。此字段不得包含用于填充或NUL字符终止的额外八位字节。此名称的语法和语义未在本文档中指定，因为它们可能因产品和/或操作系统而异。姿态收集器可以在单个“已安装的软件包”属性中列出两个名称相同的软件包。这里没有定义这样做的含义。
Version Len
版本Len
This field is an unsigned 8-bit integer that indicates the length of the Package Version Number field in octets. This field may be zero if a Package Version Number is not available.
此字段是一个无符号8位整数，表示包版本号字段的长度（以八位字节为单位）。如果包版本号不可用，则此字段可能为零。
Package Version Number
软件包版本号
This field contains the version string for the package named in the previous Package Name field. This field is a UTF-8 encoded character string whose octet length is given by the Version Len field. This field MUST NOT include extra octets for padding or NUL character termination. The syntax and semantics of this version string are not specified in this document, since they may vary across products and/or operating systems. Posture Collectors
此字段包含前一个包名称字段中命名的包的版本字符串。此字段是UTF-8编码字符串，其八位字节长度由版本Len字段给出。此字段不得包含用于填充或NUL字符终止的额外八位字节。本文档中未指定此版本字符串的语法和语义，因为它们可能因产品和/或操作系统而异。姿态采集器
MAY list two packages with the same Package Version Number (and even the same Package Name and Package Version Number) in a single Installed Packages attribute. The meaning of doing so is not defined here.
可以在单个Installed packages属性中列出具有相同软件包版本号（甚至相同软件包名称和软件包版本号）的两个软件包。这里没有定义这样做的含义。
This PA-TNC Attribute Type contains an error code and supplemental information regarding an error pertaining to PA-TNC.
此PA-TNC属性类型包含错误代码和有关PA-TNC错误的补充信息。
All Posture Collectors and Posture Validators that implement any of the IETF Standard PA Subtypes defined in this specification MUST support sending and receiving this attribute type, at least for those PA subtypes.
实现本规范中定义的任何IETF标准PA子类型的所有姿态采集器和姿态验证器必须支持发送和接收此属性类型，至少对于这些PA子类型。
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 8. The value in the PA-TNC Attribute Length field will vary, depending on the length of the Error Information field. However, the value in the PA-TNC Attribute Length field MUST be at least 20 because this is the length of the fixed-length fields in the PA-TNC Attribute Header and the fixed-length fields in this attribute type.
对于此属性类型，PA-TNC属性供应商ID字段必须设置为零（0），PA-TNC属性类型字段必须设置为8。PA-TNC属性长度字段中的值将根据错误信息字段的长度而变化。但是，PA-TNC属性长度字段中的值必须至少为20，因为这是PA-TNC属性头中的固定长度字段和此属性类型中的固定长度字段的长度。
A PA-TNC error code SHOULD be sent with the same PA Message Vendor ID and PA Subtype used by the PA-TNC message that caused the error so that the error code is sent to the party who sent the offending PA-TNC message. Other measures (such as setting PB-TNC's EXCL flag and Posture Collector Identifier or Posture Validator Identifier fields) SHOULD also be taken to attempt to ensure that only the party who sent the offending message receives the error.
PA-TNC错误代码应与导致错误的PA-TNC消息使用的PA消息供应商ID和PA子类型相同，以便将错误代码发送给发送违规PA-TNC消息的一方。还应采取其他措施（如设置PB-TNC的EXCL标志和姿势收集器标识符或姿势验证器标识符字段），以确保只有发送违规消息的一方收到错误。
When a PA-TNC error code is received, the recipient MUST NOT respond with a PA-TNC error code because this could result in an infinite loop of errors. Instead, the recipient MAY log the error, modify its behavior to attempt to avoid the error (attempting to avoid loops or long strings of 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).
当收到PA-TNC错误代码时，收件人不得使用PA-TNC错误代码进行响应，因为这可能导致错误的无限循环。相反，接收方可以记录错误、修改其行为以尝试避免错误（尝试避免循环或长串错误）、忽略错误、终止评估或采取其他适当的措施（只要符合本规范的要求）。
Posture Validators MUST NOT include this attribute type in an Attribute Request attribute. It does not make sense for a Posture Validator to request that a Posture Collector send a PA-TNC Error attribute.
姿态验证器不得在属性请求属性中包含此属性类型。姿势验证器请求姿势收集器发送PA-TNC错误属性是没有意义的。
The following diagram illustrates the format and contents of the Attribute Value field for this attribute type. The text after this diagram describes the fields shown here.
下图说明了此属性类型的属性值字段的格式和内容。此图后面的文本描述了此处显示的字段。
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 | PA-TNC Error Code Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Information (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 | PA-TNC Error Code Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Information (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
含蓄的
This field is reserved for future use. This field MUST be set to 0 on transmission and ignored upon reception.
此字段保留供将来使用。此字段在传输时必须设置为0，在接收时忽略。
PA-TNC Error Code Vendor ID
PA-TNC错误代码供应商ID
This field contains the SMI Private Enterprise Number for the organization that defined the PA-TNC Error Code that is being used in the attribute. For IETF Standard PA-TNC Error Code values this field MUST be set to zero (0).
此字段包含定义属性中使用的PA-TNC错误代码的组织的SMI私有企业号。对于IETF标准PA-TNC错误代码值，此字段必须设置为零（0）。
PA-TNC Error Code
PA-TNC错误代码
This field contains the PA-TNC Error Code being reported in this attribute. Note that a particular PA-TNC Error Code value will have completely different meanings depending on the PA-TNC Error Code Vendor ID. Each PA-TNC Error Code Vendor ID defines a different space of PA-TNC Error Code values. Posture Collectors and Posture Validators MUST NOT require support for particular vendor-specific PA-TNC Error Codes and MUST interoperate with other parties despite any differences in the set of vendor-specific PA-TNC Error Codes supported (although they MAY permit administrators to configure them to require support for specific PA-TNC Error Codes).
此字段包含此属性中报告的PA-TNC错误代码。请注意，根据PA-TNC错误代码供应商ID，特定PA-TNC错误代码值将具有完全不同的含义。每个PA-TNC错误代码供应商ID定义了不同的PA-TNC错误代码值空间。姿态采集器和姿态验证器不得要求支持特定供应商特定的PA-TNC错误代码，并且必须与其他方互操作，尽管所支持的特定供应商PA-TNC错误代码集存在任何差异（尽管它们可能允许管理员将其配置为需要特定PA-TNC错误代码的支持）。
When the PA-TNC Error Code Vendor ID is set to zero (0), the PA-TNC Error Code is an IETF Standard PA-TNC Error Code. IANA maintains a registry of PA-TNC Error Codes. Entries in this registry are added by Expert Review with Specification Required, following the guidelines in section 7.
当PA-TNC错误代码供应商ID设置为零（0）时，PA-TNC错误代码为IETF标准PA-TNC错误代码。IANA维护PA-TNC错误代码的注册表。根据第7节中的指南，通过专家评审添加此注册表中的条目，并提供所需的规范。
The following table lists the IETF Standard PA-TNC Error Codes defined in this specification:
下表列出了本规范中定义的IETF标准PA-TNC错误代码：
Integer Description
------- -----------
0 Reserved
1 Invalid Parameter
2 Version Not Supported
3 Attribute Type Not Supported
Integer Description
------- -----------
0 Reserved
1 Invalid Parameter
2 Version Not Supported
3 Attribute Type Not Supported
The next few subsections of this document provide detailed definitions of these error codes.
本文档接下来的几个小节提供了这些错误代码的详细定义。
Error Information
错误信息
This field provides additional context for the error. The contents of this field vary based on the PA-TNC Error Code Vendor ID and PA-TNC Error Code. Therefore, whenever a PA-TNC Error Code is defined, the format of this field for that error code must also be defined. The definitions of IETF Standard PA-TNC Error Codes on the next few pages provide good examples of such definitions.
此字段提供错误的其他上下文。此字段的内容因PA-TNC错误代码供应商ID和PA-TNC错误代码而异。因此，无论何时定义PA-TNC错误代码，都必须定义该错误代码的此字段格式。接下来几页中IETF标准PA-TNC错误代码的定义提供了此类定义的良好示例。
The length of this field can be determined by the recipient using the PA-TNC Attribute Length field by subtracting the length of the fixed-length fields in the PA-TNC Attribute Header and the fixed-length fields in this attribute.
收件人可使用PA-TNC属性长度字段，通过减去PA-TNC属性头中固定长度字段的长度和该属性中固定长度字段的长度来确定此字段的长度。
The Invalid Parameter error code is an IETF Standard PA-TNC Error Code (value 1) that indicates that the sender of this error code has detected an invalid value in a PA-TNC message sent by the recipient of this error code in the current assessment.
无效参数错误代码是IETF标准PA-TNC错误代码（值1），表示该错误代码的发送方在当前评估中检测到该错误代码的接收方发送的PA-TNC消息中存在无效值。
For this error code, the Error Information field contains the first 8 octets of the PA-TNC message that contained the invalid parameter and an offset indicating the position within that message of the invalid parameter.
对于此错误代码，错误信息字段包含包含无效参数的PA-TNC消息的前8个八位字节，以及指示无效参数在该消息中的位置的偏移量。
The following diagram illustrates the format and contents of the Error Information field for this error code. The text after this diagram describes the fields shown here.
下图说明了此错误代码的错误信息字段的格式和内容。此图后面的文本描述了此处显示的字段。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Copy of Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Copy of Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
版本
This field MUST contain an exact copy of the Version field in the PA-TNC Message Header of the PA-TNC message that caused this error.
此字段必须包含导致此错误的PA-TNC消息的PA-TNC消息头中版本字段的精确副本。
Copy of Reserved
保留副本
This field MUST contain an exact copy of the Reserved field in the PA-TNC Message Header of the PA-TNC message that caused this error.
此字段必须包含导致此错误的PA-TNC消息的PA-TNC消息头中保留字段的精确副本。
Message Identifier
消息标识符
This field MUST contain an exact copy of the Message Identifier field in the PA-TNC Message Header of the PA-TNC message that caused this error.
此字段必须包含导致此错误的PA-TNC消息的PA-TNC消息头中消息标识符字段的精确副本。
Offset
抵消
This field MUST contain an octet offset from the start of the PA-TNC Message Header of the PA-TNC message that caused this error to the start of the value that caused this error. For instance, if the first PA-TNC attribute in the message had an invalid PA-TNC Attribute Length (e.g., 0), this value would be 16.
此字段必须包含从导致此错误的PA-TNC消息的PA-TNC消息头的开头到导致此错误的值的开头的八位字节偏移量。例如，如果消息中的第一个PA-TNC属性具有无效的PA-TNC属性长度（例如，0），则该值将为16。
The Version Not Supported error code is an IETF Standard PA-TNC Error Code (value 2) that indicates that the sender of this error code does not support the PA-TNC version number included in the PA-TNC Message Header of a PA-TNC message sent by the recipient of this error code in the current assessment.
版本不受支持的错误代码是IETF标准PA-TNC错误代码（值2），表示该错误代码的发送方不支持当前评估中该错误代码的接收方发送的PA-TNC消息的PA-TNC消息头中包含的PA-TNC版本号。
For this error code, the Error Information field contains the first 8 octets of the PA-TNC message that contained the unsupported version as well as Max Version and Min Version fields that indicate which PA-TNC version numbers are supported by the sender of the error code.
对于此错误代码，错误信息字段包含PA-TNC消息的前8个八位字节，其中包含不受支持的版本，以及指示错误代码发送方支持哪些PA-TNC版本号的最大版本和最小版本字段。
The sender MUST support all PA-TNC versions between the Min Version and the Max Version, inclusive (i.e., including the Min Version and the Max Version). When possible, recipients of this error code SHOULD send future messages to the Posture Collector or Posture Validator that originated this error message with a PA-TNC version number within the stated range.
发送方必须支持最低版本和最高版本（包括最低版本和最高版本）之间的所有PA-TNC版本。如果可能，此错误代码的接收者应将未来的消息发送给发出此错误消息的姿态收集器或姿态验证器，其PA-TNC版本号在规定范围内。
Any party that is sending the Version Not Supported error code MUST include that error code as the only PA-TNC attribute in a PA-TNC message with version number 1. All parties that send PA-TNC messages MUST be able to properly process a message that meets this description, even if they cannot process any other aspect of PA-TNC version 1. This ensures that a PA-TNC version exchange can proceed properly, no matter what versions of PA-TNC the parties implement.
发送版本不受支持的错误代码的任何一方必须将该错误代码作为版本号为1的PA-TNC消息中唯一的PA-TNC属性。发送PA-TNC消息的所有各方必须能够正确处理符合此描述的消息，即使他们无法处理PA-TNC版本1的任何其他方面。这确保了PA-TNC版本交换可以正常进行，无论双方实施的是什么版本的PA-TNC。
The following diagram illustrates the format and contents of the Error Information field for this error code. The text after this diagram describes the fields shown here.
下图说明了此错误代码的错误信息字段的格式和内容。此图后面的文本描述了此处显示的字段。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Copy of Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Version | Min Version | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Copy of Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Version | Min Version | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
版本
This field MUST contain an exact copy of the Version field in the PA-TNC Message Header of the PA-TNC message that caused this error.
此字段必须包含导致此错误的PA-TNC消息的PA-TNC消息头中版本字段的精确副本。
Copy of Reserved
保留副本
This field MUST contain an exact copy of the Reserved field in the PA-TNC Message Header of the PA-TNC message that caused this error.
此字段必须包含导致此错误的PA-TNC消息的PA-TNC消息头中保留字段的精确副本。
Message Identifier
消息标识符
This field MUST contain an exact copy of the Message Identifier field in the PA-TNC Message Header of the PA-TNC message that caused this error.
此字段必须包含导致此错误的PA-TNC消息的PA-TNC消息头中消息标识符字段的精确副本。
Max Version
最大版本
This field MUST contain the maximum PA-TNC version supported by the sender of this error code.
此字段必须包含此错误代码的发件人支持的最大PA-TNC版本。
Min Version
最小版本
This field MUST contain the minimum PA-TNC version supported by the sender of this error code.
此字段必须包含此错误代码的发件人支持的最低PA-TNC版本。
Reserved
含蓄的
Reserved for future use. This field MUST be set to 0 on transmission and ignored upon reception.
保留供将来使用。此字段在传输时必须设置为0，在接收时忽略。
The Attribute Type Not Supported error code is an IETF Standard PA-TNC Error Code (value 3) that indicates that the sender of this error code does not support the PA-TNC Attribute Type included in the Error Information field. This PA-TNC Attribute Type was included in a PA-TNC message sent by the recipient of this error code in the current assessment.
属性类型不支持的错误代码是IETF标准PA-TNC错误代码（值3），表示此错误代码的发送方不支持错误信息字段中包含的PA-TNC属性类型。此PA-TNC属性类型包含在当前评估中此错误代码的收件人发送的PA-TNC消息中。
For this error code, the Error Information field contains the first 8 octets of the PA-TNC message that contained the unsupported attribute type as well as a copy of the attribute type that caused the problem.
对于此错误代码，错误信息字段包含PA-TNC消息的前8个八位字节，其中包含不受支持的属性类型以及导致问题的属性类型的副本。
The following diagram illustrates the format and contents of the Error Information field for this error code. The text after this diagram describes the fields shown here.
下图说明了此错误代码的错误信息字段的格式和内容。此图后面的文本描述了此处显示的字段。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Copy of Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | PA-TNC Attribute Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Copy of Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | PA-TNC Attribute Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
版本
This field MUST contain an exact copy of the Version field in the PA-TNC Message Header of the PA-TNC message that caused this error.
此字段必须包含导致此错误的PA-TNC消息的PA-TNC消息头中版本字段的精确副本。
Copy of Reserved
保留副本
This field MUST contain an exact copy of the Reserved field in the PA-TNC Message Header of the PA-TNC message that caused this error.
此字段必须包含导致此错误的PA-TNC消息的PA-TNC消息头中保留字段的精确副本。
Message Identifier
消息标识符
This field MUST contain an exact copy of the Message Identifier field in the PA-TNC Message Header of the PA-TNC message that caused this error.
此字段必须包含导致此错误的PA-TNC消息的PA-TNC消息头中消息标识符字段的精确副本。
Flags
旗帜
This field MUST contain an exact copy of the Flags field in the PA-TNC Attribute Header of the PA-TNC attribute that caused this error.
此字段必须包含导致此错误的PA-TNC属性的PA-TNC属性头中标志字段的精确副本。
PA-TNC Attribute Vendor ID
PA-TNC属性供应商ID
This field MUST contain an exact copy of the PA-TNC Attribute Vendor ID field in the PA-TNC Attribute Header of the PA-TNC attribute that caused this error.
此字段必须包含导致此错误的PA-TNC属性的PA-TNC属性标题中PA-TNC属性供应商ID字段的精确副本。
PA-TNC Attribute Type
PA-TNC属性类型
This field MUST contain an exact copy of the PA-TNC Attribute Type field in the PA-TNC Attribute Header of the PA-TNC attribute that caused this error.
此字段必须包含导致此错误的PA-TNC属性的PA-TNC属性头中PA-TNC属性类型字段的精确副本。
This PA-TNC attribute contains the final assessment result from a particular Posture Validator. This attribute might be returned to a Posture Collector for information purposes such as when an endpoint is compliant. Similarly, the Assessment Result attribute could be sent to indicate a non-compliant result where specific actions are needed to bring an endpoint into compliance with the network's policies. These actions could be defined in other PA-TNC attributes such as Remediation Instructions sent to the Posture Collector.
此PA-TNC属性包含特定姿势验证器的最终评估结果。此属性可能会返回给姿势收集器，以用于信息目的，例如端点符合要求时。类似地，可以发送“评估结果”属性，以指示不符合要求的结果，其中需要采取特定措施使端点符合网络策略。这些动作可以在其他PA-TNC属性中定义，例如发送到姿态收集器的修正指令。
All Posture Collectors that support an IETF Standard PA Subtype defined in this specification SHOULD support receiving and processing the Assessment Result attribute. All Posture Validators that implement an IETF Standard PA Subtype defined in this specification SHOULD support sending the Assessment Result attribute.
支持本规范中定义的IETF标准PA子类型的所有姿态采集器应支持接收和处理评估结果属性。实现本规范中定义的IETF标准PA子类型的所有姿势验证器应支持发送评估结果属性。
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 9.
对于此属性类型，PA-TNC属性供应商ID字段必须设置为零（0），PA-TNC属性类型字段必须设置为9。
The following diagram illustrates the format and contents of the Attribute Value field for this attribute type. The text after this diagram describes the fields shown here.
下图说明了此属性类型的属性值字段的格式和内容。此图后面的文本描述了此处显示的字段。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assessment Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assessment Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Assessment Result
评估结果
This 32-bit field MUST contain one of the following values;
此32位字段必须包含以下值之一：；
Value Description
----- -----------
0 Posture Validator assessed the endpoint component to
be compliant with policy.
Value Description
----- -----------
0 Posture Validator assessed the endpoint component to
be compliant with policy.
1 Posture Validator assessed the endpoint component to be non-compliant with policy but the difference from compliant was minor.
1姿态验证器评估端点组件不符合策略，但与符合的差异很小。
2 Posture Validator assessed the endpoint component to be non-compliant with policy and the assessed difference was very significant.
2姿势验证器评估终点成分不符合政策，评估差异非常显著。
3 Posture Validator was unable to determine policy compliance of an endpoint component due to an error.
3由于错误，姿态验证程序无法确定终结点组件的策略符合性。
4 Posture Validator was unable to determine whether the assessed endpoint component was compliant with policy based on the attributes provided by the Posture Collector.
4姿势验证器无法根据姿势收集器提供的属性确定评估的端点组件是否符合策略。
This PA-TNC attribute sent by the Posture Validator to the Posture Collector contains remediation instructions for updating a particular component to make the endpoint compliant with the assessment policies. A Posture Validator might choose to send more than one Remediation Instructions attribute in some circumstances (e.g., both a URI and a human-readable message are necessary) to remediate one or more components. This attribute supports the inclusion of either an IETF standard or vendor-specific remediation instruction.
姿势验证器发送给姿势收集器的此PA-TNC属性包含更新特定组件以使端点符合评估策略的修正说明。在某些情况下（例如，URI和人类可读消息都是必需的），姿势验证器可能会选择发送多个修正指令属性来修正一个或多个组件。此属性支持包含IETF标准或供应商特定的修复指令。
All Posture Collectors that implement an IETF Standard PA Subtype defined in this specification SHOULD support receiving and processing the Remediation Instructions attribute. All Posture Validators that implement an IETF Standard PA Subtype defined in this specification SHOULD support sending this attribute type. Posture Collectors and Posture Validators supporting other non-IETF standard components MAY support this attribute.
实现本规范中定义的IETF标准PA子类型的所有姿态采集器应支持接收和处理“修正指令”属性。实现本规范中定义的IETF标准PA子类型的所有姿态验证器都应支持发送此属性类型。支持其他非IETF标准组件的姿态采集器和姿态验证器可能支持此属性。
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 10.
对于此属性类型，PA-TNC属性供应商ID字段必须设置为零（0），PA-TNC属性类型字段必须设置为10。
The following diagram illustrates the format and contents of the Attribute Value field for this attribute type. The text after this diagram describes the fields shown here.
下图说明了此属性类型的属性值字段的格式和内容。此图后面的文本描述了此处显示的字段。
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 | Remediation Parameters Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation Parameters Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation Parameters (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 | Remediation Parameters Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation Parameters Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation Parameters (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved (8 bits)
保留（8位）
The Reserved bits MUST be set to 0 on transmission and ignored on reception.
传输时保留位必须设置为0，接收时忽略。
Remediation Parameters Vendor ID (24 bits)
补救参数供应商ID（24位）
The Remediation Parameters Vendor ID field identifies a vendor by using the SMI Private Enterprise Number (PEN). Any organization can receive its own unique PEN from IANA, the Internet Assigned Numbers Authority. The Remediation Parameters Vendor ID qualifies the Remediation Parameters Type field so that each vendor has 2^32 separate Remediation Parameters Types available for its use. Remediation Parameters Types standardized by the IETF are always used with the value zero (0) in this field.
补救参数供应商ID字段使用SMI私有企业编号（PEN）标识供应商。任何组织都可以从IANA（互联网分配号码管理机构）收到自己的唯一PEN。修正参数供应商ID限定修正参数类型字段，以便每个供应商有2^32个单独的修正参数类型可供其使用。IETF标准化的修复参数类型始终与该字段中的值零（0）一起使用。
Remediation Parameters Type (32 bits)
修正参数类型（32位）
The Remediation Parameters Type field identifies the different types of remediation instructions that can be contained in the Remediation Parameters field. IANA maintains a registry of PA-TNC Remediation Parameters Types. Entries in this registry are added by Expert Review with Specification Required, following the guidelines in section 7. A list of IETF Standard PA-TNC Remediation Parameters Types defined in this specification appears later in this section.
“修正参数类型”字段标识可包含在“修正参数”字段中的不同类型的修正说明。IANA维护PA-TNC修复参数类型的注册表。根据第7节中的指南，通过专家评审添加此注册表中的条目，并提供所需的规范。本节后面将列出本规范中定义的IETF标准PA-TNC修复参数类型列表。
New vendor-specific remediation instructions can be created by adding new Remediation Parameters Types (those used with a non-zero Remediation Parameters vendor ID) without IETF or IANA involvement. Posture Collectors and Posture Validators MUST NOT require support for particular vendor-specific PA-TNC Remediation Parameters Types and MUST interoperate with other parties despite any differences in the set of vendor-specific PA-TNC Remediation Parameters Types supported (although they MAY permit administrators to configure them to require support for specific PA-TNC remediation parameter types).
在不涉及IETF或IANA的情况下，可以通过添加新的修正参数类型（与非零修正参数供应商ID一起使用的类型）来创建新的供应商特定修正指令。姿态采集器和姿态验证器不得要求支持特定供应商特定的PA-TNC修正参数类型，并且必须与其他方进行互操作，尽管所支持的特定供应商PA-TNC修正参数类型集存在任何差异（尽管它们可能允许管理员将其配置为需要特定PA-TNC修复参数类型的支持）。
The following table lists the IETF Standard PA-TNC Remediation Parameters Type values defined in this specification:
下表列出了本规范中定义的IETF标准PA-TNC修复参数类型值：
Integer Description
------- -----------
0 Reserved
1 Remediation URI
2 Remediation String
Integer Description
------- -----------
0 Reserved
1 Remediation URI
2 Remediation String
The next few subsections of this document provide detailed definitions of the contents of the Remediation Parameters field used with each Remediation Parameter Type.
本文档接下来的几个小节提供了与每种修正参数类型一起使用的修正参数字段内容的详细定义。
Remediation Parameters (variable length)
修正参数（可变长度）
The Remediation Parameters field contains the actual remediation instructions for the Posture Collector.
修正参数字段包含姿势收集器的实际修正说明。
The Remediation URI Parameters Type is an IETF Standard Remediation Parameters Type (value 1) that indicates that the sending Posture Validator is providing a URI to instructions on how to remediate the endpoint.
修正URI参数类型是IETF标准修正参数类型（值1），表示发送姿态验证器正在向有关如何修正端点的指令提供URI。
The following diagram illustrates the format and contents of the Remediation Parameters field when carrying a Remediation URI parameter. The text after this diagram describes the fields shown here.
下图说明了携带修正URI参数时修正参数字段的格式和内容。此图后面的文本描述了此处显示的字段。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation URI (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation URI (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Remediation URI
补救URI
The Remediation URI field MUST contain a URI, as described in RFC 3986 [7]. This URI SHOULD contain instructions to update a particular component so that it might result in the component being compliant with the policies in future assessments. Posture Collectors should validate that the URI and instructions come from a trustworthy source to avoid being tricked into performing damaging actions (see security considerations).
修正URI字段必须包含URI，如RFC 3986[7]所述。此URI应包含更新特定组件的说明，以便在将来的评估中使组件符合策略。姿态收集器应验证URI和指令是否来自可靠来源，以避免被欺骗执行破坏性操作（请参阅安全注意事项）。
The Remediation String Parameters Type is an IETF Standard Remediation Parameters Type (value 2) that indicates that the sending Posture Validator is providing a human-readable string containing instructions on how to remediate the endpoint.
修正字符串参数类型是IETF标准修正参数类型（值2），表示发送姿势验证器正在提供一个人类可读的字符串，其中包含有关如何修正端点的说明。
The following diagram illustrates the format and contents of the Remediation Parameters field when the carrying a Remediation String parameter. The text after this diagram describes the fields shown here.
下图说明了当包含修正字符串参数时，修正参数字段的格式和内容。此图后面的文本描述了此处显示的字段。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation String Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation String (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lang Code Len | Remediation String Lang Code (Variable Len) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation String Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation String (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lang Code Len | Remediation String Lang Code (Variable Len) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Remediation String Length
修正字符串长度
The Remediation String Length contains the length of the Remediation String field in octets.
修正字符串长度包含修正字符串字段的长度（以八位字节为单位）。
Remediation String
修复字符串
The Remediation String field MUST contain a UTF-8 encoded string. This string contains human-readable instructions for remediation that MAY be displayed to the user by the Posture Collector. NUL termination MUST NOT be included. If a Posture Collector receives a Remediation String that does contain a NUL termination, it SHOULD send an Invalid Parameter error code.
修正字符串字段必须包含UTF-8编码的字符串。此字符串包含可由姿态收集器向用户显示的人类可读的修正说明。不得包括NUL终止。如果姿态收集器接收到包含NUL终止的修正字符串，则应发送无效的参数错误代码。
Lang Code Len (Remediation String Language Code Length)
语言代码长度（修正字符串语言代码长度）
The Lang Code Len field contains the length of the Remediation String Language Code field in octets.
Lang Code Len字段包含修复字符串语言代码字段的长度（以八位字节为单位）。
Remediation String Lang Code
修正字符串Lang代码
The Remediation String Lang(uage) Code field contains a US-ASCII string composed of a well-formed RFC 4646 [6] language tag that indicates the language(s) used in the Remediation String in the Remediation Parameters field. A zero-length string MAY be sent for this field (essentially omitting this field) to indicate that the language code for the remediation string is not known.
修正字符串Lang（uage）代码字段包含一个US-ASCII字符串，该字符串由格式良好的RFC 4646[6]语言标记组成，该标记指示修正参数字段中修正字符串中使用的语言。可能会为此字段发送一个长度为零的字符串（基本上忽略此字段），以指示修正字符串的语言代码未知。
This PA-TNC attribute indicates whether the endpoint is forwarding traffic between interfaces. Endpoints that forward traffic between networks connected to multiple network interfaces may be considered non-compliant (and a security risk) in some enterprise network deployments. For example, an endpoint with multiple connected network interfaces might allow traffic from an interface connected to a public network to be forwarded through another interface carrying a VPN session to a protected enterprise network. This attribute is
此PA-TNC属性指示端点是否在接口之间转发流量。在某些企业网络部署中，在连接到多个网络接口的网络之间转发流量的端点可能被视为不符合要求（并且存在安全风险）。例如，具有多个连接的网络接口的端点可能允许来自连接到公共网络的接口的流量通过另一个承载VPN会话的接口转发到受保护的企业网络。此属性是
currently envisioned to be specific to reporting posture for the operating system component; however, could be useful for other future types of components.
当前设想为特定于操作系统组件的报告姿态；但是，它可能对未来其他类型的组件有用。
Posture Collectors that implement the IETF Standard PA Subtype for Operating System SHOULD support sending the Forwarding Enabled attribute. Posture Collectors that do not implement the Operating System PA Subtype defined in this specification SHOULD NOT send the Forwarding Enabled attribute unless it is appropriate to their PA Subtype. Whether a particular Posture Collector actually sends this attribute type SHOULD still be governed by local privacy and security policies. Posture Validators that implement the IETF Standard PA Subtype for Operating System SHOULD support receiving the Forwarding Enabled attribute type. Posture Validators supporting components other than Operating System MAY support receiving this attribute type if it is appropriate to their PA Subtype. A Posture Validator that does not support receiving this attribute type SHOULD simply ignore attributes with this type. Posture Validators MUST NOT send this attribute type.
为操作系统实现IETF标准PA子类型的姿态采集器应支持发送启用转发的属性。未实现本规范中定义的操作系统PA子类型的姿态采集器不应发送启用转发的属性，除非该属性适合其PA子类型。特定的姿态收集器是否实际发送此属性类型仍应由本地隐私和安全策略控制。为操作系统实现IETF标准PA子类型的姿态验证器应支持接收启用转发的属性类型。支持操作系统以外组件的姿态验证器可能支持接收此属性类型（如果该属性类型适合其PA子类型）。不支持接收此属性类型的姿势验证器应忽略具有此类型的属性。姿态验证器不能发送此属性类型。
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 11.
对于此属性类型，PA-TNC属性供应商ID字段必须设置为零（0），PA-TNC属性类型字段必须设置为11。
The following diagram illustrates the format and contents of the Attribute Value field for this attribute type. The text after this diagram describes the fields shown here.
下图说明了此属性类型的属性值字段的格式和内容。此图后面的文本描述了此处显示的字段。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding Enabled |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding Enabled |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Forwarding Enabled
启用转发
This 32-bit field MUST contain one of the following values;
此32位字段必须包含以下值之一：；
Value Description
----- -----------
0 Disabled - Endpoint is not forwarding traffic.
Value Description
----- -----------
0 Disabled - Endpoint is not forwarding traffic.
1 Enabled - Endpoint is forwarding traffic.
1已启用-终结点正在转发流量。
2 Unknown - Unable to determine whether endpoint is forwarding traffic
2未知-无法确定终结点是否正在转发流量
This PA-TNC attribute indicates whether the endpoint has a factory default password enabled for use. Some types of endpoints include a default static password for used to gain privileged access to the endpoint. If this password is not changed or disabled before the endpoint is accessible on the network, it's often easy to compromise the endpoint.
此PA-TNC属性指示端点是否启用了出厂默认密码以供使用。某些类型的端点包括默认的静态密码，用于获得对端点的特权访问。如果在网络上访问端点之前未更改或禁用此密码，则通常很容易破坏端点。
Posture Collectors that implement the IETF Standard PA Subtype for Operating System SHOULD support sending the Factory Default Password Enabled attribute. Posture Collectors that implement other IETF Standard PA Subtypes defined in this specification SHOULD NOT support sending this attribute type for those PA subtypes. Other Posture Collectors MAY support sending this attribute type, if it is appropriate to their PA subtype. Whether a particular Posture Collector actually sends this attribute type SHOULD still be governed by local privacy and security policies. Posture Validators that implement the IETF Standard PA Subtype for Operating System SHOULD support receiving the Factory Default Password Enabled attribute. Other Posture Validators MAY support receiving this attribute type. A Posture Validator that does not support receiving this attribute type SHOULD simply ignore attributes with this type. Posture Validators MUST NOT send this attribute type.
为操作系统实现IETF标准PA子类型的姿态采集器应支持发送出厂默认密码启用属性。实现本规范中定义的其他IETF标准PA子类型的姿态采集器不应支持为这些PA子类型发送此属性类型。其他姿态采集器可能支持发送此属性类型（如果适合其PA子类型）。特定的姿态收集器是否实际发送此属性类型仍应由本地隐私和安全策略控制。为操作系统实现IETF标准PA子类型的姿态验证器应支持接收出厂默认密码启用属性。其他姿势验证器可能支持接收此属性类型。不支持接收此属性类型的姿势验证器应忽略具有此类型的属性。姿态验证器不能发送此属性类型。
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 12.
对于此属性类型，PA-TNC属性供应商ID字段必须设置为零（0），PA-TNC属性类型字段必须设置为12。
The following diagram illustrates the format and contents of the Attribute Value field for this attribute type. The text after this diagram describes the fields shown here.
下图说明了此属性类型的属性值字段的格式和内容。此图后面的文本描述了此处显示的字段。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Factory Default Password Enabled |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Factory Default Password Enabled |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Factory Default Password Enabled
出厂默认密码已启用
This 32-bit field MUST contain one of the following values;
此32位字段必须包含以下值之一：；
Value Description
----- -----------
0 Endpoint does not have factory default password enabled.
Value Description
----- -----------
0 Endpoint does not have factory default password enabled.
1 Endpoint has a factory default password enabled.
1终结点已启用出厂默认密码。
This section discusses the use of vendor-defined attributes within PA-TNC. The PA-TNC protocol was designed to allow for vendor-defined attributes to be used as a replacement where a standard attribute could be used. In some cases, even the standard attributes allow for vendor-defined information to be included. It is envisioned that over time as particular vendor-defined attributes become popular, an equivalent standard attribute could be added allowing for broader interoperability.
本节讨论在PA-TNC中使用供应商定义的属性。PA-TNC协议旨在允许供应商定义的属性用作可使用标准属性的替代品。在某些情况下，甚至标准属性也允许包含供应商定义的信息。可以预见，随着时间的推移，随着特定供应商定义属性的流行，可以添加一个等效的标准属性，以实现更广泛的互操作性。
This specification does not define vendor-defined attributes, but rather highlights how such attributes can be used with PA-TNC without the potential for namespace collisions or misinterpretations. In order to avoid collisions, PA-TNC uses the well-established SMI Private Enterprise Numbers as vendor IDs to define separate namespaces for important fields within a PA-TNC message. For example, to ensure the uniqueness of attribute types while providing for vendor extensions, vendor-defined attribute types include the vendor's unique vendor ID, to indicate the intended namespace for the attribute type, followed by the attribute type. IETF Standard PA-TNC Attribute Types use a vendor ID of zero (0).
本规范没有定义供应商定义的属性，而是强调如何将这些属性与PA-TNC一起使用，而不存在名称空间冲突或误解的可能性。为了避免冲突，PA-TNC使用公认的SMI私有企业编号作为供应商ID，为PA-TNC消息中的重要字段定义单独的名称空间。例如，为了在提供供应商扩展时确保属性类型的唯一性，供应商定义的属性类型包括供应商的唯一供应商ID，以指示属性类型的预期名称空间，然后是属性类型。IETF标准PA-TNC属性类型使用零（0）的供应商ID。
SMI Private Enterprise Numbers are used to provide a separate identifier space for each vendor. The IANA provides a registry for SMI Private Enterprise Numbers. Any organization (including non-profit organizations, governmental bodies, etc.) can obtain one of these numbers at no charge, and thousands of organizations have done so. Within this document, SMI Private Enterprise Numbers are known as "vendor IDs".
SMI私有企业编号用于为每个供应商提供单独的标识符空间。IANA提供SMI私有企业编号的注册。任何组织（包括非营利组织、政府机构等）都可以免费获得其中一个号码，已有数千个组织这样做。在本文档中，SMI私有企业编号称为“供应商ID”。
This section discusses the major potential types of security threats relevant to the PA-TNC message protocol. It is envisioned that additional attribute types could be defined in the future to facilitate the exchange of security capabilities, keys, and security protected attributes if future use cases are adopted that require such protections.
本节讨论与PA-TNC消息协议相关的主要潜在安全威胁类型。可以预见，如果将来采用需要此类保护的用例，将来可以定义其他属性类型，以促进安全功能、密钥和安全保护属性的交换。
In order to understand where security countermeasures are necessary, this section starts with a discussion of where the TNC architecture envisions some trust relationships between the processing elements of the PA-TNC protocol. The following subsections discuss the trust properties associated with each portion of the NEA reference model directly involved with the processing of the PA-TNC protocol.
为了理解哪里需要安全对策，本节首先讨论TNC体系结构在哪里设想PA-TNC协议的处理元素之间的一些信任关系。以下小节讨论与PA-TNC协议处理直接相关的NEA参考模型各部分相关的信任属性。
The Posture Collectors are trusted by Posture Validators to:
姿态验证器信任姿态采集器：
o Collect valid information about the component type associated with the Posture Collector
o 收集与姿势收集器关联的组件类型的有效信息
o Report upon collected information consistent with local security and privacy policies
o 报告收集到的符合当地安全和隐私政策的信息
o Accurately report information associated with the type of component for the PA-TNC message
o 准确报告与PA-TNC消息组件类型相关的信息
o Not act maliciously to the Posture Broker Server and Posture Validators, including attacks such as denial of service
o 不要恶意操作姿态代理服务器和姿态验证程序，包括拒绝服务等攻击
The Posture Validators are trusted by Posture Collectors to:
姿态采集器信任姿态验证器：
o Only request information necessary to assess the security state of the endpoint
o 仅请求评估端点安全状态所需的信息
o Make assessment decisions based on deployer-defined policies
o 根据部署人员定义的策略做出评估决策
o Discard collected information consistent with data retention and privacy policies
o 丢弃收集的符合数据保留和隐私策略的信息
o Not act maliciously to the Posture Broker Server and Posture Collectors, including attacks such as denial of service
o 不要恶意操作姿态代理服务器和姿态收集器，包括拒绝服务等攻击
o Not send malicious remediation instructions that do not fix or that cause damage to the endpoint
o 不要发送不修复或对端点造成损坏的恶意补救指令
The Posture Broker Client and Posture Broker Server are trusted by the Posture Collector and Posture Validator to:
姿态收集器和姿态验证器信任姿态代理客户端和姿态代理服务器：
o Provide a reliable transport for PA-TNC messages
o 为PA-TNC消息提供可靠的传输
o Deliver messages for a particular PA Subtype only to those Posture Collectors and Posture Validators that have registered for them
o 仅将特定PA子类型的消息传递给已注册的姿势收集器和姿势验证器
o Not disclose any provided attributes to unauthorized parties
o 不得向未经授权方披露任何提供的属性
o Not act maliciously to drop messages, duplicate messages, or flood Posture Collectors and Posture Validators with unnecessary messages
o 不要恶意删除消息、复制消息或使用不必要的消息淹没姿态收集器和姿态验证器
o Not observe, fabricate, or alter the contents of a PA-TNC message
o 不得观察、捏造或更改PA-TNC信息的内容
o Properly place Posture Collector and Posture Validator identifiers into the PB-TNC protocol, deliver those identifiers to Posture Collectors and Posture Validators as needed, and manage exclusive delivery to a particular Posture Collector or Posture Validator when requested
o 正确地将姿势收集器和姿势验证器标识符放入PB-TNC协议中，根据需要将这些标识符传递给姿势收集器和姿势验证器，并在请求时管理对特定姿势收集器或姿势验证器的独占传递
o Properly expose authentication information from PT security so that Posture Collectors and Posture Validators can use the peer's identity information to safely make policy decisions
o 正确地公开来自PT security的身份验证信息，以便姿态收集器和姿态验证器可以使用对等方的身份信息安全地做出策略决策
Beyond the trusted relationships assumed in section 5.1, the PA-TNC protocol faces a number of potential security attacks that could require security countermeasures.
除了第5.1节中假定的信任关系之外，PA-TNC协议还面临许多可能需要安全对策的潜在安全攻击。
Generally, the PA-TNC protocol relies upon the underlying PT protocol's security to protect the messages from attack when traveling over the network. Once the message resides on the Posture Broker Client or Posture Broker Server, the posture brokers are trusted to properly and safely deliver the messages to the appropriate Posture Collectors and Posture Validators.
通常，PA-TNC协议依赖于底层PT协议的安全性来保护消息在网络上传输时免受攻击。一旦消息驻留在姿态代理客户端或姿态代理服务器上，就会信任姿态代理将消息正确、安全地传递给适当的姿态收集器和姿态验证器。
When PA-TNC messages are sent over unprotected network links or spanning local software stacks that are not trusted, the contents of the PA-TNC 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. Attributes observed by eavesdroppers could contain information that exposes potential weaknesses in the security of the endpoint, or system fingerprinting information easing the ability of the attacker to employ attacks more likely to be successful against the endpoint. The eavesdropper might also learn information about the endpoint or network policies that either singularly or collectively is considered sensitive information (e.g., certain endpoints are lacking patches, or particular sub-networks have more lenient policies).
当PA-TNC消息通过不受保护的网络链路或跨越不受信任的本地软件栈发送时，PA-TNC消息的内容可能会被中间方窃取信息。这种盗窃行为可能会导致记录信息供对手将来使用或分析。窃听者观察到的属性可能包含暴露端点安全性中潜在弱点的信息，或系统指纹信息，从而降低攻击者对端点实施更可能成功的攻击的能力。窃听者还可能了解关于端点或网络策略的信息，这些信息单独或集体地被视为敏感信息（例如，某些端点缺少补丁，或者特定子网络具有更宽松的策略）。
PA-TNC attributes are not intended to carry privacy-sensitive information, but should some exist in a message, the adversary could come into possession of the information, which could be used for
PA-TNC属性不打算携带隐私敏感信息，但如果消息中存在某些信息，则对手可能会拥有这些信息，这些信息可用于
financial gain. Therefore, it is important that PT provide strong confidentiality protection to protect the message from eavesdroppers when being sent between the Posture Transport Client and Posture Transport Server.
财务收益。因此，当在姿态传输客户端和姿态传输服务器之间发送消息时，PT必须提供强大的保密保护，以保护消息不被窃听。
Attackers on the network or present within the NEA system could introduce fabricated PA-TNC messages intending to trick or create a denial of service against aspects of an assessment. For example, an adversary could attempt to send a falsified set of remediation instructions using the Remediation URI support in hopes of the Posture Collector automatically following the instructions. Posture Collectors need to ensure that any requests to take actions on the endpoint (such as remediation instructions) received from Posture Validators are authentic and trustworthy using strong authentication and integrity protections offered by PT. Posture Collectors should not blindly follow remediation instructions received from a trusted NEA Server. At least for patches and other potentially dangerous actions, Posture Collectors should validate these actions (e.g., via user confirmation) before proceeding.
网络上或NEA系统内的攻击者可能会引入伪造的PA-TNC消息，以欺骗或创建针对评估方面的拒绝服务。例如，对手可以尝试使用修正URI支持发送一组伪造的修正指令，希望姿态收集器能够自动遵循这些指令。姿态采集器需要使用PT提供的强大身份验证和完整性保护，确保从姿态验证器收到的对端点采取行动的任何请求（如补救指令）都是真实可信的。姿态采集器不应盲目遵循从受信任的NEA服务器收到的修正指令。至少对于补丁和其他潜在的危险动作，姿势收集器应在继续之前验证这些动作（例如，通过用户确认）。
Such an attack could occur if an active attacker launches a man-in-the-middle (MitM) attack by proxying the PA-TNC messages and was able to replace undesired messages with ones easing future attack upon the endpoint. Consider a scenario where PT security protection is not used and the Posture Broker Server proxies all assessment traffic to a remote Posture Broker Server. The proxy could eavesdrop and replace assessment results attributes, tricking the endpoint into thinking it has passed an assessment, when in fact it has not and requires remediation. Because the Posture Collector has no way to verify that attributes were actually created by an authentic Posture Validator, it is unable to detect the falsified attribute or message. Therefore, it is important that PT provides strong authentication and integrity protection.
如果主动攻击者通过代理PA-TNC消息发起中间人（MitM）攻击，并能够将不需要的消息替换为缓解将来对端点的攻击的消息，则可能发生此类攻击。考虑不使用PT安全保护的情况，姿态代理服务器将所有评估流量委托给远程姿态代理服务器。代理可以窃听并替换评估结果属性，诱使端点认为它已经通过了评估，而事实上它没有通过，并且需要补救。由于姿势收集器无法验证属性是否由真实的姿势验证器实际创建，因此无法检测伪造的属性或消息。因此，PT提供强大的身份验证和完整性保护非常重要。
This attack could allow an active attacker capable of intercepting a message to modify a PA-TNC message attribute to a desired value to ease the compromise of an endpoint. Without the ability for message recipients to detect whether a received message contains the same content as what was originally sent, active attackers can stealthily modify the attribute exchange.
此攻击可使能够截获消息的主动攻击者将PA-TNC消息属性修改为所需值，以缓解对端点的危害。由于消息收件人无法检测接收到的消息是否包含与最初发送的消息相同的内容，主动攻击者可以秘密修改属性交换。
For example, an attacker might wish to change the contents of the firewall component's version string attribute to disguise the fact that the firewall is running an old, vulnerable version. The
例如，攻击者可能希望更改防火墙组件的version string属性的内容，以掩盖防火墙正在运行旧的易受攻击的版本这一事实。这个
attacker would change the version string sent by the firewall Posture Collector to the current version number, so the Posture Validator's assessment passes while leaving the endpoint vulnerable to attack. Similarly, an attacker could achieve widespread denial of service by altering large numbers of assessments' version string attributes to an old value so they repeatedly fail assessments even after a successful remediation. Upon receiving the lower value, the Posture Validator would continue to believe that the endpoint is running old, potentially vulnerable versions of the firewall that does not meet network compliance policy, so therefore the endpoint would not be allowed to join the network. Use of a PT protocol providing strong integrity protection and authentication is essential as countermeasures to these attacks.
攻击者会将防火墙姿态收集器发送的版本字符串更改为当前版本号，这样姿态验证器的评估通过，同时使端点容易受到攻击。类似地，攻击者可以通过将大量评估的版本字符串属性更改为旧值来实现广泛的拒绝服务，这样即使在成功修复后，他们也会反复失败评估。收到较低的值后，姿态验证器将继续认为端点运行的是旧的、可能有漏洞的防火墙版本，不符合网络合规性策略，因此不允许端点加入网络。使用PT协议提供强大的完整性保护和身份验证是应对这些攻击的关键。
Another potential attack against an unprotected PA-TNC message attribute exchange is to exploit the lack of a strong binding between the attributes sent during an assessment to the specific endpoint. Without a strong binding of the endpoint to the posture information, an attacker could record the attributes sent during an assessment of a compliant endpoint and later replay those attributes so that a non-compliant endpoint can now gain access to the network or protected resource. This attack could be employed by a network MitM that is able to eavesdrop and proxy message exchanges, or by using local rogue agents on the endpoints. Assessments lacking some form of freshness exchange could be subject to replay of prior assessment data, even if it no longer reflects the current state of the endpoint. Use of a PT protocol providing strong integrity protection and authentication including a freshness exchange is necessary countermeasure to these attacks.
针对未受保护的PA-TNC消息属性交换的另一种潜在攻击是利用评估期间发送到特定端点的属性之间缺乏强绑定的漏洞。如果端点与姿势信息没有强绑定，攻击者可以记录在评估兼容端点期间发送的属性，然后重播这些属性，以便不兼容端点现在可以访问网络或受保护的资源。此攻击可由能够窃听和代理消息交换的网络MitM使用，或通过在端点上使用本地恶意代理使用。缺乏某种形式新鲜度交换的评估可能会受到先前评估数据重播的影响，即使它不再反映终点的当前状态。使用PT协议提供强大的完整性保护和身份验证，包括新鲜度交换，是应对这些攻击的必要措施。
Similar to the attribute modification attacks, an adversary wishing to include one or more attributes or PA-TNC messages inside a valid assessment may be able to insert the attributes or messages without detection by the recipient. For example, an attacker could add attributes to the front of a PA-TNC message to cause an assessment to succeed even for a non-compliant endpoint, particularly if it knew that the recipient ignored repeated attributes within a message. Similarly, if a Posture Collector or Posture Validator always generated an error if it saw unexpected attributes, the attacker could cause failures and denial of service by adding attributes or messages to an exchange. Use of a PT protocol providing strong authentication and integrity protection could prevent the adversary from inserting attributes into the assessment.
与属性修改攻击类似，希望在有效评估中包含一个或多个属性或PA-TNC消息的对手可能能够插入属性或消息，而无需接收方检测。例如，攻击者可以将属性添加到PA-TNC消息的前端，以使评估即使对于不符合要求的端点也能成功，特别是当攻击者知道收件人忽略了消息中的重复属性时。类似地，如果姿态收集器或姿态验证器在看到意外属性时总是生成错误，则攻击者可以通过向exchange添加属性或消息来导致失败和拒绝服务。使用提供强大身份验证和完整性保护的PT协议可以防止对手在评估中插入属性。
A variety of types of denial-of-service attacks are possible against the PA-TNC message exchange if left unprotected from untrusted parties along the communication path between the Posture Collector and Posture Validator. Normally, the PT exchange is bidirectionally authenticated, which helps to prevent a MitM on the network from becoming an active proxy, but transparent message routing gateways may still exist on the communication path and can modify the integrity of the message exchange unless adequate integrity protection is provided. If the MitM or other entities on the network can send messages to the Posture Broker Client or Posture Broker Server that appear to be part of an assessment, these messages could confuse the Posture Collector and Posture Validator or cause them to perform unnecessary work or take incorrect action. Several example denial-of-service situations are described in sections 5.2.3 and 5.2.5. Many potential denial-of-service examples exist, including flooding messages to the Posture Collector or Posture Validator, sending very large messages containing many attributes, and repeatedly asking for resource-intensive operations.
如果在姿态采集器和姿态验证器之间的通信路径上不受不信任方的保护，PA-TNC消息交换可能遭受多种类型的拒绝服务攻击。通常，PT交换是双向认证的，这有助于防止网络上的MitM成为活动代理，但是透明消息路由网关可能仍然存在于通信路径上，并且可以修改消息交换的完整性，除非提供足够的完整性保护。如果MitM或网络上的其他实体可以向姿态代理客户端或姿态代理服务器发送看似是评估的一部分的消息，这些消息可能会混淆姿态收集器和姿态验证器，或导致它们执行不必要的工作或采取不正确的操作。第5.2.3节和第5.2.5节描述了几种拒绝服务情况示例。存在许多潜在的拒绝服务示例，包括向姿态收集器或姿态验证器发送大量消息、发送包含许多属性的非常大的消息，以及反复请求资源密集型操作。
The PA-TNC protocol is designed to allow for controlled disclosure of security-relevant information about an endpoint, specifically for the purpose of enabling an assessment of the endpoint's compliance with network policy. The purpose of this protocol is to provide visibility into the state of the protective mechanisms on the endpoint, in order for the Posture Validators and Posture Broker Server to determine whether the endpoint is up to date and thus has the best chance of being resilient in the face of malware threats. One risk associated with providing visibility into the contents of an endpoint is the increased chance for exposure of privacy-sensitive information without the consent of the user.
PA-TNC协议旨在允许受控披露有关端点的安全相关信息，特别是为了评估端点是否符合网络策略。此协议的目的是提供对端点上保护机制状态的可见性，以便姿态验证器和姿态代理服务器确定端点是否是最新的，从而在面临恶意软件威胁时具有最好的恢复能力。与提供端点内容可视性相关的一个风险是未经用户同意而暴露隐私敏感信息的机会增加。
While this protocol does provide the Posture Validator the ability to request specific information about the endpoint, the protocol is not open ended, bounding the Posture Validator to only query specific information (attributes) about specific security features (component types) of the endpoint. Each PA-TNC message is explicitly about a single component from the list of components in section 3.5. These components include a list of security-related aspects of the endpoint that affect the ability of the endpoint to resist attacks and thus are of interest during an assessment. Discretionary components used by the user to create or view content are not on the list, as they are more likely to have access to privacy-sensitive information.
虽然该协议确实为姿态验证器提供了请求有关端点的特定信息的能力，但该协议不是开放式的，它将姿态验证器限定为仅查询有关端点的特定安全特性（组件类型）的特定信息（属性）。每个PA-TNC消息都明确涉及第3.5节组件列表中的单个组件。这些组件包括端点的安全相关方面的列表，这些方面影响端点抵抗攻击的能力，因此在评估过程中非常重要。用户用于创建或查看内容的任意组件不在列表中，因为它们更有可能访问隐私敏感信息。
Similarly, PA-TNC messages contain a set of attributes that describe the particular component. Each attribute contains generic information (e.g., product information or versions) about the component, so it is unlikely to include any user-specific or identifying information. This combination of a limited set of security-related components with non-user-specific attributes greatly reduces the risk of exposure of privacy-sensitive information. Vendors that choose to define additional component types and/or attributes within their namespace are encouraged to provide similar constraints.
类似地，PA-TNC消息包含一组描述特定组件的属性。每个属性都包含有关组件的通用信息（例如，产品信息或版本），因此不太可能包含任何特定于用户的信息或标识信息。将有限的一组安全相关组件与非用户特定属性结合在一起，可以大大降低暴露隐私敏感信息的风险。鼓励选择在其名称空间中定义其他组件类型和/或属性的供应商提供类似的约束。
Even with the bounding of standard attribute information to specific components, it is possible that individuals might wish to share less information with different networks they wish to access. For example, a user may wish to share more information when connecting to or being reassessed by the user's employer network than what would be made available to the local coffee shop wireless network. While these situations do not impact the protocol itself, they do suggest that Posture Collector implementations should consider supporting a privacy filter allowing the user and/or system owner to restrict access to certain attributes based upon the target network.
即使将标准属性信息绑定到特定组件，个人也可能希望与他们希望访问的不同网络共享较少的信息。例如，当连接到用户的雇主网络或被用户的雇主网络重新评估时，用户可能希望共享比本地咖啡店无线网络可用的信息更多的信息。虽然这些情况不影响协议本身，但它们确实建议姿势收集器实现应该考虑支持允许用户和/或系统所有者基于目标网络限制对某些属性的访问的隐私过滤器。
The underlying PT protocol authenticates the network's Posture Broker Server at the start of an assessment, so identity can be made available to the Posture Collector and per-network privacy filtering is possible. Network owners should make available a list of the attributes they require to perform an assessment and any privacy policy they enforce when handling the data. Users wishing to use a more restricted privacy filter on the endpoint may risk not being able to pass an assessment and thus not gain access to the requested network or resource.
基础PT协议在评估开始时对网络的姿态代理服务器进行身份验证，因此姿态收集器可以使用身份，并且可以进行每个网络的隐私过滤。网络所有者应提供执行评估所需的属性列表，以及处理数据时执行的任何隐私政策。希望在端点上使用更受限制的隐私过滤器的用户可能无法通过评估，从而无法访问请求的网络或资源。
This section defines the contents of three new IANA registries: PA-TNC Attribute Types, PA-TNC Error Codes, and PA-TNC Remediation Parameters Types. This section explains how these registries work. Also, this specification defines several new PA Subtypes for use with PA-TNC.
本节定义了三个新IANA注册表的内容：PA-TNC属性类型、PA-TNC错误代码和PA-TNC修复参数类型。本节介绍这些注册表的工作原理。此外，本规范还定义了几个新的PA子类型，用于PA-TNC。
All of the registries defined in this document support IETF standard values and vendor-defined values. To explain this phenomenon, we will use the PA-TNC Attribute Type as an example, but the other three registries work the same way. Whenever a PA-TNC Attribute 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 PA-TNC Attribute Type is an IETF standard value listed in the IANA registry for PA-TNC Attribute
本文档中定义的所有注册表都支持IETF标准值和供应商定义值。为了解释这种现象，我们将以PA-TNC属性类型为例，但其他三个注册中心的工作方式相同。每当PA-TNC属性类型出现在网络上时，它总是伴随着SMI私有企业号（PEN），也称为供应商ID。如果该供应商ID为零，则伴随的PA-TNC属性类型是IANA注册表中列出的PA-TNC属性的IETF标准值
Types, and its meaning is defined in the specification listed for that PA-TNC Attribute Type in that registry. If the vendor ID is not zero, the meaning of the PA-TNC Attribute 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 PA-TNC Attribute Types used with their vendor ID and publish a specification for each of these values.
类型，其含义在该注册表中为该PA-TNC属性类型列出的规范中定义。如果供应商ID不为零，则PA-TNC属性类型的含义由供应商ID标识的供应商定义（如IANA注册中心SMI PENs中所列）。鼓励已识别的供应商，但不要求其向IANA注册其供应商ID使用的部分或全部PA-TNC属性类型，并发布这些值的规范。
This delegation of namespace is analogous to the technique used for OIDs. It can result in interoperability problems if vendors require support for particular vendor-specific values. However, such behavior is explicitly prohibited by this specification (in section 4.1), which dictates that "Posture Collectors and Posture Validators MUST NOT require support for particular vendor-specific PA-TNC Attribute Types and MUST interoperate with other parties despite any differences in the set of vendor-specific PA-TNC Attribute Types supported (although they MAY permit administrators to configure them to require support for specific PA-TNC Attribute Types)". Similar requirements are included for PA Subtypes, Remediation Parameters Types, and PA-TNC Error Codes.
名称空间的这种委托类似于用于OID的技术。如果供应商需要支持特定于供应商的值，则可能会导致互操作性问题。但是，本规范（第4.1节）明确禁止此类行为，其中规定：“姿态采集器和姿态验证器不得要求支持特定于供应商的PA-TNC属性类型，并且必须与其他方进行互操作，尽管所支持的特定于供应商的PA-TNC属性类型集存在任何差异（尽管它们可能允许管理员将其配置为需要特定PA-TNC属性类型的支持）”。PA子类型、修正参数类型和PA-TNC错误代码也包含类似的要求。
For all of the IANA registries defined by this specification, new values are added to the registry by Expert Review with Specification Required, using the Designated Expert process defined in RFC 5226 [3].
对于本规范定义的所有IANA注册中心，使用RFC 5226[3]中定义的指定专家流程，通过专家评审将新值添加到注册中心，并符合规范要求。
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 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 MUST be documented in a specification that is permanently and publicly available. IETF standard 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 standard 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 MUST 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对该副本进行存档，并在某个时候，如果文件不再通过其他渠道免费提供给所有人，则该副本将免费提供给所有人。
Section 7.2 defines the new PA Subtypes. The following three sections provide guidance to the IANA in creating and managing the new IANA registries defined by this specification.
第7.2节定义了新的PA子类型。以下三节为IANA创建和管理本规范定义的新IANA注册中心提供了指导。
Section 3.5 of this specification defines several new PA Subtypes that have been added to the PA Subtypes registry defined in the PB-TNC specification. Here is a list of these assignments:
本规范第3.5节定义了几个新的PA子类型，它们已添加到PB-TNC规范中定义的PA子类型注册表中。以下是这些作业的列表：
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 0 Testing RFC 5792
0 1 Operating System RFC 5792
0 2 Anti-Virus RFC 5792
0 3 Anti-Spyware RFC 5792
0 4 Anti-Malware RFC 5792
0 5 Firewall RFC 5792
0 6 IDPS RFC 5792
0 7 VPN RFC 5792
0 8 NEA Client RFC 5792
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 0 Testing RFC 5792
0 1 Operating System RFC 5792
0 2 Anti-Virus RFC 5792
0 3 Anti-Spyware RFC 5792
0 4 Anti-Malware RFC 5792
0 5 Firewall RFC 5792
0 6 IDPS RFC 5792
0 7 VPN RFC 5792
0 8 NEA Client RFC 5792
These PA Subtypes have been added to the registry for PA Subtypes defined in the PB-TNC specification, with this RFC as the reference.
这些PA子类型已添加到PB-TNC规范中定义的PA子类型注册表中，并以该RFC为参考。
The name for this registry is "PA-TNC Attribute Types". Each entry in this registry should include a human-readable name, an SMI Private Enterprise Number, a decimal integer value between 0 and 2^32-1, and a reference to the specification where the contents of this attribute type are defined. This specification must define the meaning of this PA-TNC attribute type and the format and semantics of the PA-TNC Attribute Value field for PA-TNC attributes that include the designated Private Enterprise Number in the PA-TNC Attribute Vendor ID field and the designated numeric value in the PA-TNC Attribute Type field.
此注册表的名称为“PA-TNC属性类型”。此注册表中的每个条目应包括一个可读名称、一个SMI私有企业编号、一个介于0和2^32-1之间的十进制整数值，以及对定义此属性类型内容的规范的引用。本规范必须定义PA-TNC属性类型的含义以及PA-TNC属性的PA-TNC属性值字段的格式和语义，PA-TNC属性包括PA-TNC属性供应商ID字段中指定的私有企业编号和PA-TNC属性类型字段中指定的数值。
The following entries for this registry are defined in this document. They are the initial entries in the registry for PA-TNC Attribute Types. Additional entries to this registry are added by Expert Review with Specification Required, following the guidelines in section 7.1.
本文档中定义了此注册表的以下条目。它们是注册中心中PA-TNC属性类型的初始项。根据第7.1节中的指南，通过专家评审添加本登记册的其他条目，并提供所需的规范。
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 0 Testing RFC 5792
0 1 Attribute Request RFC 5792
0 2 Product Information RFC 5792
0 3 Numeric Version RFC 5792
0 4 String Version RFC 5792
0 5 Operational Status RFC 5792
0 6 Port Filter RFC 5792
0 7 Installed Packages RFC 5792
0 8 PA-TNC Error RFC 5792
0 9 Assessment Result RFC 5792
0 10 Remediation Instructions RFC 5792
0 11 Forwarding Enabled RFC 5792
0 12 Factory Default Password RFC 5792
Enabled
0 0xffffffff Reserved RFC 5792
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 0 Testing RFC 5792
0 1 Attribute Request RFC 5792
0 2 Product Information RFC 5792
0 3 Numeric Version RFC 5792
0 4 String Version RFC 5792
0 5 Operational Status RFC 5792
0 6 Port Filter RFC 5792
0 7 Installed Packages RFC 5792
0 8 PA-TNC Error RFC 5792
0 9 Assessment Result RFC 5792
0 10 Remediation Instructions RFC 5792
0 11 Forwarding Enabled RFC 5792
0 12 Factory Default Password RFC 5792
Enabled
0 0xffffffff Reserved RFC 5792
The name for this registry is "PA-TNC 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 2^32-1, and a reference to the specification where this error code is defined. This specification must define the meaning of this error code and the format and semantics of the Error Information field for PA-TNC attributes that have a PA-TNC vendor ID of 0, a PA-TNC Attribute Type of PA-TNC Error, the designated Private Enterprise Number in the PA-TNC Error Code Vendor ID field, and the designated numeric value in the PA-TNC Error Code field.
此注册表的名称为“PA-TNC错误代码”。此注册表中的每个条目应包括一个可读名称、一个SMI私有企业编号、一个介于0和2^32-1之间的十进制整数值，以及对定义此错误代码的规范的引用。本规范必须为PA-TNC供应商ID为0、PA-TNC属性类型为PA-TNC错误、PA-TNC错误代码供应商ID字段中指定的私有企业编号的PA-TNC属性定义此错误代码的含义以及错误信息字段的格式和语义，以及PA-TNC错误代码字段中的指定数值。
The following entries for this registry are defined in this document. They are the initial entries in the registry for PA-TNC Error Codes. Additional entries to this registry are added by Expert Review with Specification Required, following the guidelines in section 7.1.
本文档中定义了此注册表的以下条目。它们是PA-TNC错误代码注册表中的初始条目。根据第7.1节中的指南，通过专家评审添加本登记册的其他条目，并提供所需的规范。
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 0 Reserved RFC 5792
0 1 Invalid Parameter RFC 5792
0 2 Version Not Supported RFC 5792
0 3 Attribute Type Not Supported RFC 5792
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 0 Reserved RFC 5792
0 1 Invalid Parameter RFC 5792
0 2 Version Not Supported RFC 5792
0 3 Attribute Type Not Supported RFC 5792
The name for this registry is "PA-TNC Remediation Parameters Types". Each entry in this registry should include a human-readable name, an SMI Private Enterprise Number, a decimal integer value between 1 and 2^32-1, and a reference to the specification where the contents of this remediation parameters type are defined. This specification must define the meaning of this PA-TNC Remediation Parameters Type and the format and semantics of the Remediation Parameters field for PA-TNC attributes that include the designated Private Enterprise Number in the Remediation Parameters Vendor ID field and the designated numeric value in the Remediation Parameters Type field.
此注册表的名称为“PA-TNC修复参数类型”。此注册表中的每个条目应包括一个可读名称、一个SMI私有企业编号、一个介于1和2^32-1之间的十进制整数值，以及一个对定义此修正参数类型内容的规范的引用。本规范必须定义此PA-TNC补救参数类型的含义以及PA-TNC属性的补救参数字段的格式和语义，这些属性包括补救参数供应商ID字段中指定的私有企业编号和补救参数类型字段中指定的数值。
The following entries for this registry are defined in this document. They are the initial entries in the registry for PA-TNC Remediation Parameters Types. Additional entries to this registry are added by Expert Review with Specification Required, following the guidelines in section 7.1.
本文档中定义了此注册表的以下条目。它们是PA-TNC修复参数类型注册表中的初始条目。根据第7.1节中的指南，通过专家评审添加本登记册的其他条目，并提供所需的规范。
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 0 Reserved RFC 5792
0 1 URI RFC 5792
0 2 Remediation String RFC 5792
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 0 Reserved RFC 5792
0 1 URI RFC 5792
0 2 Remediation String RFC 5792
Thanks to the Trusted Computing Group for contributing the initial text [8] upon which this document was based. The authors 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: Stuart Bailey, Roger Chickering, Lauren Giroux, Charles Goldberg, Steve Hanna, Ryan Hurst, Meenakshi Kaushik, Greg Kazmierczak, Scott Kelly, PJ Kirner, Houcheng Lee, Lisa Lorenzin, Mahalingam Mani, Sung Lee, Ravi Sahita, Mauricio Sanchez, Brad Upson, and Han Yin.
感谢Trusted Computing Group提供了本文档所基于的初始文本[8]。作者还想感谢以下对本文件或其前身的编写做出贡献或提供实质性投入的人士：斯图尔特·贝利、罗杰·奇克林、劳伦·吉鲁、查尔斯·戈德伯格、史蒂夫·汉纳、瑞安·赫斯特、米纳基·考希克、格雷格·卡兹米尔扎克、斯科特·凯利、PJ·基尔纳、李后成，丽莎·洛伦津、玛哈林根·马尼、李成、拉维·萨希塔、毛里西奥·桑切斯、布拉德·厄普森和韩茵。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[2] Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[3] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[4] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[4] Klyne，G.和C.Newman，“互联网上的日期和时间：时间戳”，RFC 33392002年7月。
[5] 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.
[5] Sahita，R.，Hanna，S.，Hurst，R.，和K.Narayan，“PB-TNC：与可信网络连接（TNC）兼容的姿态代理（PB）协议”，RFC 5793，2010年3月。
[6] Phillips, A., Ed., and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[6] Phillips，A.，Ed.，和M.Davis，Ed.，“识别语言的标签”，BCP 47，RFC 5646，2009年9月。
[7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[7] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[8] Trusted Computing Group, "IF-M: TLV Binding", http://www.trustedcomputinggroup.org/resources/ tnc_ifm_tlv_binding_specification, February 2010.
[8] 可信计算组，“IF-M:TLV绑定”，http://www.trustedcomputinggroup.org/resources/ tnc_ifm_tlv_绑定_规范，2010年2月。
[9] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, June 2008.
[9] Sangster，P.，Khosravi，H.，Mani，M.，Narayan，K.，和J.Tardo，“网络端点评估（NEA）：概述和要求”，RFC 52092008年6月。
This scenario involves the assessment of an endpoint initiated during network join. The assessment is triggered by the Posture Broker Client (PBC) and involves collection of patch information from both Standard Operating System (OS) Posture Collector and vendor-specific Patch Posture Collector (PC). The assessment by both the vendor-specific Patch Posture Validator (PV) and Standard OS Posture Validator result in a compliant assessment decision that results in a compliant System Assessment Decision to be returned by the Posture Broker Server (PBS).
此场景涉及对网络连接期间启动的端点的评估。评估由姿态代理客户端（PBC）触发，包括从标准操作系统（OS）姿态收集器和供应商特定的补丁姿态收集器（PC）收集补丁信息。特定于供应商的补丁姿态验证器（PV）和标准操作系统姿态验证器的评估都会产生符合要求的评估决策，从而导致姿态代理服务器（PBS）返回符合要求的系统评估决策。
+--------+ +-------+ +---------+ +--------+ +-------++--------+
| Vndr. X| | Std. | | Std. | | Std. | | Std. || Vndr. X|
|Patch PC| | OS PC | | PBC | | PBS | | OS PV ||Patch PV|
+--+-----+ +-+-----+ +---+-----+ +-+------+ +-+------+--+-----+
| | N/W Join| | | |
| | ----->| | | |
| | Req Post. | | | |
| |<----------| | | |
| | Req Post. | | | |
|<--------------------| | | |
|Vndr X Patch Posture | | | |
|-------------------->| | | |
| |OS Posture | | | |
| |---------->| | | |
| | | Posture | | |
| | | Report | | |
| | |-------->| | |
| | | | Verify | |
| | | | Posture | |
| | | |---------> |
| | | | | Verify |
| | | | | Posture |
| | | |------------------->|
| | | | OS Reslt | |
| | | |<---------| |
| | | | VndrX Patch Result |
| | | Assess |<-------------------|
| | | Result | |
| | |<--------| | |
| | OS Reslt | | | |
| |<----------| | | |
| VndrX Patch Result | | | |
|<--------------------| | | |
+--------+ +-------+ +---------+ +--------+ +-------++--------+
| Vndr. X| | Std. | | Std. | | Std. | | Std. || Vndr. X|
|Patch PC| | OS PC | | PBC | | PBS | | OS PV ||Patch PV|
+--+-----+ +-+-----+ +---+-----+ +-+------+ +-+------+--+-----+
| | N/W Join| | | |
| | ----->| | | |
| | Req Post. | | | |
| |<----------| | | |
| | Req Post. | | | |
|<--------------------| | | |
|Vndr X Patch Posture | | | |
|-------------------->| | | |
| |OS Posture | | | |
| |---------->| | | |
| | | Posture | | |
| | | Report | | |
| | |-------->| | |
| | | | Verify | |
| | | | Posture | |
| | | |---------> |
| | | | | Verify |
| | | | | Posture |
| | | |------------------->|
| | | | OS Reslt | |
| | | |<---------| |
| | | | VndrX Patch Result |
| | | Assess |<-------------------|
| | | Result | |
| | |<--------| | |
| | OS Reslt | | | |
| |<----------| | | |
| VndrX Patch Result | | | |
|<--------------------| | | |
This section shows the contents of the key fields in each of the PA messages exchanged in this use case. When necessary, additional commentary is provided to explain why certain fields contain the shown values. Note that many of the flows shown are between components on the same system so no message contents are shown.
本节显示了在本用例中交换的每个PA消息中的关键字段的内容。必要时，提供附加注释，解释某些字段包含显示值的原因。请注意，显示的许多流是在同一系统上的组件之间的，因此不显示任何消息内容。
This flow represents the event that causes the PBC to decide to start an assessment of the endpoint in order to gain access to the network. This is merely an event and does not include a message being sent.
此流表示导致PBC决定开始端点评估以获得网络访问权的事件。这只是一个事件，不包括正在发送的消息。
This flow illustrates an invocation of the OS and patch posture collectors requesting particular posture attributes to be sent. Because this use case is triggered locally, the contents of this flow aren't specified by NEA.
此流程演示了对操作系统和补丁姿态收集器的调用，请求发送特定姿态属性。因为这个用例是在本地触发的，所以NEA没有指定这个流的内容。
This flow contains the PA message from the Patch Posture Collector:
此流包含来自Patch姿态收集器的PA消息：
Vendor X Patch Posture PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=1 (vendor X)
type=1 (Vendor X namespace attribute)
length
Value = {
VendorXAttribute1=123
}
}
Attribute 2 {
vendor-id=1 (vendor X)
type=2 (Vendor X namespace attribute)
length
Value = {
VendorXAttribute2=456
}
}
}
Vendor X Patch Posture PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=1 (vendor X)
type=1 (Vendor X namespace attribute)
length
Value = {
VendorXAttribute1=123
}
}
Attribute 2 {
vendor-id=1 (vendor X)
type=2 (Vendor X namespace attribute)
length
Value = {
VendorXAttribute2=456
}
}
}
This flow contains the PA message from the OS Posture Collector:
此流包含来自OS姿态采集器的PA消息：
OS Posture PA Message {
操作系统姿态PA消息{
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=2 (product information)
length
Value = {
Product-vendor-id=311 -- Microsoft's PEN
Product-name="Windows Vista"
}
}
Attribute 2 {
vendor-id=0
type=3 (numeric version)
length
Value = {
major-version=6 -- Vista is version 6.0
minor-version=0
build-number=456789
service-pack-major=0 -- No service packs
service-pack-minor=0
}
}
}
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=2 (product information)
length
Value = {
Product-vendor-id=311 -- Microsoft's PEN
Product-name="Windows Vista"
}
}
Attribute 2 {
vendor-id=0
type=3 (numeric version)
length
Value = {
major-version=6 -- Vista is version 6.0
minor-version=0
build-number=456789
service-pack-major=0 -- No service packs
service-pack-minor=0
}
}
}
This flow contains the PB message containing the PA messages from the Patch and OS Posture Collectors; the message content is described in the PB-TNC specification.
此流包含PB消息，其中包含来自补丁和OS姿态采集器的PA消息；PB-TNC规范中描述了消息内容。
This flow illustrates an invocation of the OS and patch Posture Validators requesting verification of the posture attributes received. Because this flow happens locally within the NEA server, NEA does not specify the message contents.
此流程演示了对操作系统和补丁姿态验证器的调用，请求验证接收到的姿态属性。由于此流在NEA服务器内本地发生，因此NEA不指定消息内容。
This flow contains the PA message (Posture Assessment Result) from the OS Posture Validator
此流包含来自OS姿态验证程序的PA消息（姿态评估结果）
OS Posture Result PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=9 (assessment-result)
length
Value = {
assessment-result=0 (compliant)
}
}
}
OS Posture Result PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=9 (assessment-result)
length
Value = {
assessment-result=0 (compliant)
}
}
}
This flow contains the PA message (Posture Assessment Result) from the Vendor X Patch Posture Validator
此流包含来自供应商X补丁姿态验证器的PA消息（姿态评估结果）
Patch Vendor X Posture Result PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=9 (assessment-result)
length
Value = {
assessment-result=0 (compliant)
}
}
}
Patch Vendor X Posture Result PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=9 (assessment-result)
length
Value = {
assessment-result=0 (compliant)
}
}
}
This flow contains the PB message containing the system assessment result computed by the Posture Broker Server and the PA messages from the Patch and OS Posture Validators; the message content is described in the PB-TNC specification.
该流包含PB消息，其中包含由姿态代理服务器计算的系统评估结果，以及来自补丁和OS姿态验证器的PA消息；PB-TNC规范中描述了消息内容。
These flows illustrate an invocation of the OS and Vendor X Patch Posture Collectors to receive the posture assessment results. Because this flow is triggered locally, NEA does not specify the contents of this flow.
这些流程说明了如何调用OS和供应商X补丁姿态采集器来接收姿态评估结果。由于此流是本地触发的，因此NEA不指定此流的内容。
This scenario involves the assessment of an endpoint initiated by the NEA Server. The assessment is triggered by the Posture Broker Server and involves collection of Anti-Virus attributes for two Anti-Virus components running on the endpoint. The endpoint is assessed to be compliant by one of the vendor (Vendor X) anti-virus Posture Validators and non-compliant by the other vendor (Vendor Y) anti-virus Posture Validator. Based upon the Posture Broker Server's policy, this results in a non-compliant system assessment decision to be returned by the Posture Broker Server. The Posture Broker Server also returns remediation instructions for the endpoint as part of the response.
此场景涉及对NEA服务器启动的端点的评估。该评估由姿态代理服务器触发，包括收集端点上运行的两个防病毒组件的防病毒属性。端点由一个供应商（供应商X）防病毒姿态验证器评估为符合，而由另一个供应商（供应商Y）防病毒姿态验证器评估为不符合。根据姿态代理服务器的策略，这将导致姿态代理服务器返回不符合要求的系统评估决策。姿态代理服务器还返回端点的修正指令，作为响应的一部分。
+--------+ +-------+ +---------+ +--------+ +-------+ +--------+
| Vndr Y | | Vndr X| | Std. | | Std. | | Vndr X| | Vndr Y |
| AV PC | | AV PC | | PBC | | PBS | | AV PV | | AV PV |
+----+---+ +---+---+ +-----+---+ +---+----+ +---+---+ +----+---+
| | | N/W Join| | |
| | | ------->| | |
| | | | Create | |
| | | |Post. Req | |
| | | |--------->| |
| | | |Create Posture Req |
| | | |----------+--------->|
| | | | Vndr Y AV Post Req |
| | | |<---------+----------|
| | | |Vndr X AV | |
| | | |Post. Req | |
| | | Posture |<---------| |
| | | Request | | |
| | Vndr X AV |<--------| | |
| | Post. Req | | | |
| |<----------| | | |
| Vndr Y AV | | | |
| Posture Req | | | |
+<---------+-----------| | | |
| Vndr Y AV Posture | | | |
+----------+---------->| | | |
| | Vndr X AV | | | |
| | Posture | | | |
| |---------->| Posture | | |
| | |Response | | |
| | |-------->| | |
| | | | Verify | |
| | | | Posture | |
| | | |--------->| |
| | | | Verify Posture |
| | | |----------+--------->|
| | | |Vndr Y AV Post Result|
| | | |<---------+----------|
| | | |Vndr X AV | |
| | | |Post Reslt| |
| | | Assess |<---------| |
| | | Result | | |
| | Vndr X AV |<--------| | |
| |Post Reslt |<--------| | |
| |<----------| | | |
| Vndr Y AV Post Reslt | | | |
+<---------+-----------| | | |
+--------+ +-------+ +---------+ +--------+ +-------+ +--------+
| Vndr Y | | Vndr X| | Std. | | Std. | | Vndr X| | Vndr Y |
| AV PC | | AV PC | | PBC | | PBS | | AV PV | | AV PV |
+----+---+ +---+---+ +-----+---+ +---+----+ +---+---+ +----+---+
| | | N/W Join| | |
| | | ------->| | |
| | | | Create | |
| | | |Post. Req | |
| | | |--------->| |
| | | |Create Posture Req |
| | | |----------+--------->|
| | | | Vndr Y AV Post Req |
| | | |<---------+----------|
| | | |Vndr X AV | |
| | | |Post. Req | |
| | | Posture |<---------| |
| | | Request | | |
| | Vndr X AV |<--------| | |
| | Post. Req | | | |
| |<----------| | | |
| Vndr Y AV | | | |
| Posture Req | | | |
+<---------+-----------| | | |
| Vndr Y AV Posture | | | |
+----------+---------->| | | |
| | Vndr X AV | | | |
| | Posture | | | |
| |---------->| Posture | | |
| | |Response | | |
| | |-------->| | |
| | | | Verify | |
| | | | Posture | |
| | | |--------->| |
| | | | Verify Posture |
| | | |----------+--------->|
| | | |Vndr Y AV Post Result|
| | | |<---------+----------|
| | | |Vndr X AV | |
| | | |Post Reslt| |
| | | Assess |<---------| |
| | | Result | | |
| | Vndr X AV |<--------| | |
| |Post Reslt |<--------| | |
| |<----------| | | |
| Vndr Y AV Post Reslt | | | |
+<---------+-----------| | | |
This section shows the contents of the key fields in each of the PA messages exchanged in this use case. When necessary, additional commentary is provided to explain why certain fields contain the shown values. Note that many of the flows shown are between components on the same system so no message contents are shown.
本节显示了在本用例中交换的每个PA消息中的关键字段的内容。必要时，提供附加注释，解释某些字段包含显示值的原因。请注意，显示的许多流是在同一系统上的组件之间的，因此不显示任何消息内容。
This flow represents the event that causes the PBS to decide to start an assessment of the endpoint in order to gain access to the network. This is merely an event and does not include a message being sent.
此流表示导致PBS决定开始端点评估以获得网络访问权的事件。这只是一个事件，不包括正在发送的消息。
This flow illustrates an invocation of the Vendor X and Vendor Y Anti-Virus Posture Validators enabling posture request attributes to be created. Because this use case is triggered locally, NEA does not specify the contents of this flow.
此流程演示了对供应商X和供应商Y防病毒姿态验证器的调用，以创建姿态请求属性。因为这个用例是在本地触发的，所以NEA没有指定这个流的内容。
This flow contains the PA message (Posture Request) from the Vendor Y Anti-Virus Posture Validator
此流包含来自供应商Y防病毒姿态验证程序的PA消息（姿态请求）
Vendor Y AV Posture Request PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=1 (Attribute Request)
length
Value = {
Vendor-id=0 (IETF Standard)
Type=2 (Standard attribute, Product-Information)
Vendor-id=1 (Vendor Y)
Type=2 (Vendor Y attribute, Extended-Dat-Version)
}
}
}
Vendor Y AV Posture Request PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=1 (Attribute Request)
length
Value = {
Vendor-id=0 (IETF Standard)
Type=2 (Standard attribute, Product-Information)
Vendor-id=1 (Vendor Y)
Type=2 (Vendor Y attribute, Extended-Dat-Version)
}
}
}
This flow contains the PA message (Posture Request) from the Vendor X Anti-Virus Posture Validator
此流包含来自供应商X防病毒姿态验证程序的PA消息（姿态请求）
Vendor X AV Posture Request PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=1 (Attribute Request)
length
Value = {
Vendor-id=1 (Vendor X)
Type=1 (Vendor X attribute, Scan-Engine-Version)
Vendor-id=0 (IETF Standard)
Type=5 (Standard, Operational-Status)
}
}
}
Vendor X AV Posture Request PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=1 (Attribute Request)
length
Value = {
Vendor-id=1 (Vendor X)
Type=1 (Vendor X attribute, Scan-Engine-Version)
Vendor-id=0 (IETF Standard)
Type=5 (Standard, Operational-Status)
}
}
}
This flow contains the PB message containing the PA messages from the Vendor X and Vendor Y Anti-Virus Posture Validators; the message content is described in the PB-TNC specification.
此流包含PB消息，其中包含来自供应商X和供应商Y防病毒验证程序的PA消息；PB-TNC规范中描述了消息内容。
These flows illustrate an invocation of the Vendor X and Vendor Y Anti-Virus Posture Collectors to process the Posture Request and return the particular posture attributes requested. Because this flow is triggered locally, NEA does not specify the contents of this flow.
这些流说明了如何调用供应商X和供应商Y反病毒姿态收集器来处理姿态请求并返回请求的特定姿态属性。由于此流是本地触发的，因此NEA不指定此流的内容。
This flow contains the PA message (response to the Posture Request) from the Vendor Y Anti-Virus Posture Collector.
此流包含来自供应商Y防病毒姿态收集器的PA消息（对姿态请求的响应）。
Vendor Y AV Posture PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0 (IETF Standard)
Type=2 (Standard attribute, Product-Information)
length
Value = {
product-vendor-id=12345 (vendor Y)
product-id=987 (AV product id from vendor Y)
product-name="Vendor Y Anti-Virus"
}
}
Attribute 2 {
vendor-id=2 (vendor Y)
type=2 (vendor Y attribute, DAT-Version)
length
Value = {
DAT-version=5678
}
}
}
Vendor Y AV Posture PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0 (IETF Standard)
Type=2 (Standard attribute, Product-Information)
length
Value = {
product-vendor-id=12345 (vendor Y)
product-id=987 (AV product id from vendor Y)
product-name="Vendor Y Anti-Virus"
}
}
Attribute 2 {
vendor-id=2 (vendor Y)
type=2 (vendor Y attribute, DAT-Version)
length
Value = {
DAT-version=5678
}
}
}
This flow contains the PA message (response to the Posture Request) from the Vendor X Anti-Virus Posture Collector.
此流包含来自供应商X防病毒姿态收集器的PA消息（对姿态请求的响应）。
Vendor X AV Posture PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=1
type=1 (vendor X attribute, Scan-Engine-Version)
length
Value = {
scan-engine-version=1234
}
}
Attribute 2 {
vendor-id=0 (IETF Standard)
type=5 (Standard, Operational-Status)
length
Value = {
status=2 (installed but non-operational)
result=0 (unknown)
last use="" (never used)
}
}
}
Vendor X AV Posture PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=1
type=1 (vendor X attribute, Scan-Engine-Version)
length
Value = {
scan-engine-version=1234
}
}
Attribute 2 {
vendor-id=0 (IETF Standard)
type=5 (Standard, Operational-Status)
length
Value = {
status=2 (installed but non-operational)
result=0 (unknown)
last use="" (never used)
}
}
}
This flow contains the PB message containing the PA messages from the Vendor X and Vendor Y Anti-Virus Posture Collectors; the message content is described in the PB-TNC specification.
此流包含PB消息，其中包含来自供应商X和供应商Y防病毒收集器的PA消息；PB-TNC规范中描述了消息内容。
This flow illustrates an invocation of the Vendor X and Vendor Y Anti-Virus Posture Validators requesting verification of the posture attributes received. Because this flow happens locally within the NEA server, NEA does not specify the message contents.
此流程演示了调用供应商X和供应商Y反病毒姿态验证器，请求验证收到的姿态属性。由于此流在NEA服务器内本地发生，因此NEA不指定消息内容。
This flow contains the PA message (Posture Assessment Result) from the Vendor Y Anti-Virus Posture Validator
此流包含来自供应商Y防病毒姿态验证器的PA消息（姿态评估结果）
Vendor Y AV Posture Result PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=9 (assessment-result)
length
Value = {
assessment-result=0 (compliant)
}
}
}
Vendor Y AV Posture Result PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=9 (assessment-result)
length
Value = {
assessment-result=0 (compliant)
}
}
}
This flow contains the PA message (Posture Assessment Result) from the Vendor X Anti-Virus Posture Validator
此流包含来自供应商X防病毒姿态验证器的PA消息（姿态评估结果）
Vendor X AV Posture Result PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=9 (assessment-result)
length
Value = {
assessment-result=1 (non-compliant)
}
}
}
Vendor X AV Posture Result PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=9 (assessment-result)
length
Value = {
assessment-result=1 (non-compliant)
}
}
}
This flow contains the PB message containing the system assessment result computed by the Posture Broker Server and the PA messages from the Vendor X and Vendor Y Anti-Virus Posture Validators; the message content is described in the PB-TNC specification.
此流包含PB消息，其中包含由姿态代理服务器计算的系统评估结果，以及来自供应商X和供应商Y防病毒姿态验证器的PA消息；PB-TNC规范中描述了消息内容。
These flows illustrate an invocation of the Vendor X and Vendor Y Anti-Virus Posture Collectors to receive the posture assessment results. Because this flow is triggered locally, NEA does not specify the contents of this flow.
这些流说明调用供应商X和供应商Y防病毒姿态收集器以接收姿态评估结果。由于此流是本地触发的，因此NEA不指定此流的内容。
This scenario involves the reassessment of an endpoint as a result of enabling a software component on the endpoint. The endpoint has two VPN client software components, one from vendor X for the user's home network and other from vendor Y for the network that the endpoint is currently accessing. The assessment is triggered when the user tries to use the Vendor X VPN client; this is a violation of the assessment policy. The Posture Broker Client triggers the posture assessment when it receives a notification from the VPN Posture Collector about the change to the operational state of the VPN component on the endpoint. Note that the VPN Posture Collector may support standard attributes and some vendor-defined attributes from vendor X's and vendor Y's namespaces. This use case does not leverage vendor-defined attributes. The assessment involves verification of the standard VPN posture attributes by the standard VPN Posture Validator that results in a non-compliant assessment result.
此场景涉及在端点上启用软件组件后对端点进行重新评估。端点有两个VPN客户端软件组件，一个来自供应商X，用于用户的家庭网络，另一个来自供应商Y，用于端点当前正在访问的网络。当用户尝试使用供应商X VPN客户端时触发评估；这违反了评估政策。姿态代理客户端在接收到来自VPN姿态采集器的关于端点上VPN组件操作状态更改的通知时触发姿态评估。请注意，VPN姿态收集器可能支持标准属性以及来自供应商X和供应商Y名称空间的一些供应商定义的属性。此用例不利用供应商定义的属性。评估涉及由标准VPN姿态验证器验证标准VPN姿态属性，从而导致不符合评估结果。
This use case relies on the use of multiple Posture Collector IDs for a single Posture Collector as described in section 3.3 of the PA-TNC specification. In this example, the Posture Collector will obtain two Posture Collector IDs to a single Posture Collector (Standard VPN PC) and the Posture Collector will generate two separate PA messages each using a different ID to report the posture for Vendor X and Vendor Y VPN Clients. The Posture Broker Client will associate the assigned IDs in the PB message sent to the NEA Server. This entire behavior will be completely opaque to the NEA Server, which will handle the PB message as if there were two VPN Posture Collectors on the NEA Client.
如PA-TNC规范第3.3节所述，该用例依赖于对单个姿势收集器使用多个姿势收集器ID。在此示例中，姿态采集器将向单个姿态采集器（标准VPN PC）获取两个姿态采集器ID，姿态采集器将生成两个单独的PA消息，每个消息使用不同的ID报告供应商X和供应商Y VPN客户端的姿态。姿态代理客户端将在发送到NEA服务器的PB消息中关联分配的ID。整个行为对NEA服务器来说是完全不透明的，NEA服务器将处理PB消息，就像NEA客户端上有两个VPN姿态采集器一样。
+--------+ +-------+ +---------+ +--------+ +--------+ +--------+
|Vndr X | |Vndr Y | |Standard | |Standard| |Standard| |Standard|
|VPNClnt | |VPNClnt| | VPN PC | | PBC | | PBS | | VPN PV |
+----+---+ +---+---+ +-----+---+ +---+----+ +---+----+ +----+---+
Enble| | | | | |
---->| | | | | |
| VPN Status Change | | | |
|--------------------->| Posture | | |
| | | Change | | |
| | |-------->| | |
| | |Req. Post| | |
| | |<--------| | |
| |Ins/Rq Info| | | |
| |<----------| | | |
| Inspect/Request Info | | | |
|<---------+-----------|VPNX Post| | |
| | |-------->| | |
| | |VPNY Post| | |
| | |-------->| | |
| | | | Posture | |
| | | | Report | |
| | | |--------->| |
| | | | |Vrfy Post. |
| | | | |---------->|
| | | | |VPN PRslt |
| | | | Assess |<----------|
| | | | Result | |
| | | |<---------| |
| | |VPN PRslt| | |
| | |<--------| | |
+--------+ +-------+ +---------+ +--------+ +--------+ +--------+
|Vndr X | |Vndr Y | |Standard | |Standard| |Standard| |Standard|
|VPNClnt | |VPNClnt| | VPN PC | | PBC | | PBS | | VPN PV |
+----+---+ +---+---+ +-----+---+ +---+----+ +---+----+ +----+---+
Enble| | | | | |
---->| | | | | |
| VPN Status Change | | | |
|--------------------->| Posture | | |
| | | Change | | |
| | |-------->| | |
| | |Req. Post| | |
| | |<--------| | |
| |Ins/Rq Info| | | |
| |<----------| | | |
| Inspect/Request Info | | | |
|<---------+-----------|VPNX Post| | |
| | |-------->| | |
| | |VPNY Post| | |
| | |-------->| | |
| | | | Posture | |
| | | | Report | |
| | | |--------->| |
| | | | |Vrfy Post. |
| | | | |---------->|
| | | | |VPN PRslt |
| | | | Assess |<----------|
| | | | Result | |
| | | |<---------| |
| | |VPN PRslt| | |
| | |<--------| | |
This section shows the contents of the key fields in each of the PA messages exchanged in this use case. When necessary, additional commentary is provided to explain why certain fields contain the shown values. Note that many of the flows shown are between components on the same system so no message contents are shown.
本节显示了在本用例中交换的每个PA消息中的关键字段的内容。必要时，提供附加注释，解释某些字段包含显示值的原因。请注意，显示的许多流是在同一系统上的组件之间的，因此不显示任何消息内容。
This flow represents the end user triggered event of starting the VPN Client software from Vendor X. This is merely an event and does not include a message being sent.
此流表示从供应商X启动VPN客户端软件的最终用户触发事件。这只是一个事件，不包括正在发送的消息。
This flow represents the detection of the active state of the Vendor X VPN Client software by the VPN Posture Collector. This is merely an event and does not include a message being sent.
此流表示VPN姿态采集器检测供应商X VPN客户端软件的活动状态。这只是一个事件，不包括正在发送的消息。
This flow represents the notification of the VPN posture change sent from the VPN Posture Collector to the Standard Posture Broker Client. This is merely an event and does not include a message being sent.
此流表示从VPN姿态收集器发送到标准姿态代理客户端的VPN姿态更改通知。这只是一个事件，不包括正在发送的消息。
This flow illustrates an invocation of the VPN Posture Collector requesting particular posture attributes to be sent. Because this use case is triggered locally, NEA does not specify the contents of this flow.
此流程说明了VPN姿态收集器的调用，请求发送特定姿态属性。因为这个用例是在本地触发的，所以NEA没有指定这个流的内容。
This flow illustrates the acquisition of the posture information by the VPN Posture Collector from the Vendor X and Vendor Y VPN Client components. Because this flow is triggered locally, NEA does not specify the message contents.
此流程说明了VPN姿态采集器从供应商X和供应商Y VPN客户端组件获取姿态信息的过程。由于此流是在本地触发的，因此NEA不指定消息内容。
This flow contains the PA message from the VPN Posture Collector describing the Vendor X VPN Client's posture:
此流包含来自VPN姿态收集器的PA消息，描述供应商X VPN客户端的姿态：
Vendor X VPN Posture PA Message{
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=2 (product information)
length
Value = {
product-vendor-id=9876 (vendor X)
product-id=567 (VPN client identifier for Vndr X)
product-name="Vendor X VPN Client"
}
}
Attribute 2 {
vendor-id=0
type=5 (operational status)
length
Value = {
Status=3 (Operational)
Result=1 (Successful use with no errors detected)
last Use="2008-07-07T12:00:00Z"
}
}
Vendor X VPN Posture PA Message{
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=2 (product information)
length
Value = {
product-vendor-id=9876 (vendor X)
product-id=567 (VPN client identifier for Vndr X)
product-name="Vendor X VPN Client"
}
}
Attribute 2 {
vendor-id=0
type=5 (operational status)
length
Value = {
Status=3 (Operational)
Result=1 (Successful use with no errors detected)
last Use="2008-07-07T12:00:00Z"
}
}
This flow contains the PA message from the VPN Posture Collector including the Vendor Y VPN Client's posture:
此流包含来自VPN姿态收集器的PA消息，包括供应商Y VPN客户端的姿态：
Vendor Y VPN Posture PA Message{
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=2 (product information)
length
Value = {
product-vendor-id=Vendor Y
product-id=234 (VPN client identifier for Vndr Y)
product-name="Vendor Y VPN Client"
}
}
Attribute 2 {
vendor-id=0
type=5 (operational status)
length
Value = {
Status=3 (Operational)
Result=1 (Successful use with no errors detected)
last Use="2008-07-07T14:05:00Z"
}
}
}
Vendor Y VPN Posture PA Message{
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=2 (product information)
length
Value = {
product-vendor-id=Vendor Y
product-id=234 (VPN client identifier for Vndr Y)
product-name="Vendor Y VPN Client"
}
}
Attribute 2 {
vendor-id=0
type=5 (operational status)
length
Value = {
Status=3 (Operational)
Result=1 (Successful use with no errors detected)
last Use="2008-07-07T14:05:00Z"
}
}
}
This flow contains the PB message containing the PA message from the VPN Posture Collector; the message content is described in the PB-TNC specification.
此流包含包含来自VPN姿态采集器的PA消息的PB消息；PB-TNC规范中描述了消息内容。
This flow illustrates an invocation of the VPN Posture Validator requesting verification of the posture attributes received. Because this flow happens locally within the NEA Server, NEA does not specify the message contents.
此流程说明了VPN姿态验证程序的调用，请求验证接收到的姿态属性。由于此流在NEA服务器内本地发生，因此NEA不指定消息内容。
This flow contains the PA message (Posture Assessment Result) from the VPN Posture Validator
此流包含来自VPN姿态验证程序的PA消息（姿态评估结果）
VPN Posture Result PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=9 (assessment-result)
length
Value = {
assessment-result=1 (non-compliant)
}
}
}
VPN Posture Result PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=9 (assessment-result)
length
Value = {
assessment-result=1 (non-compliant)
}
}
}
This flow contains the PB message containing the system assessment result computed by the Posture Broker Server and the PA messages from the VPN Posture Validator; the message content is described in the PB-TNC specification.
此流包含包含由姿态代理服务器计算的系统评估结果的PB消息和来自VPN姿态验证器的PA消息；PB-TNC规范中描述了消息内容。
This flow illustrates an invocation of the VPN Posture Collector to receive the posture assessment result. Because this flow is triggered locally, NEA does not specify the contents of this flow.
此流程说明了VPN姿态收集器的调用，以接收姿态评估结果。由于此流是本地触发的，因此NEA不指定此流的内容。
This section evaluates the PA-TNC protocol against the requirements defined in the NEA Requirements document. Each subsection considers a separate requirement from the NEA Requirements document. Only common requirements (C-1 through C-10) and PA requirements (PA-1 through PA-6) are considered, since these are the only ones that apply to PA.
本节根据NEA要求文件中定义的要求评估PA-TNC协议。每一小节都考虑了NEA要求文件中的单独要求。仅考虑通用要求（C-1至C-10）和PA要求（PA-1至PA-6），因为它们是唯一适用于PA的要求。
Requirement C-1 says:
要求C-1规定：
C-1 NEA protocols MUST support multiple round trips between the NEA Client and NEA Server in a single assessment.
C-1 NEA协议必须在一次评估中支持NEA客户端和NEA服务器之间的多次往返。
PA-TNC meets this requirement. It allows an unlimited number of round trips between the NEA Client and NEA Server.
PA-TNC符合这一要求。它允许NEA客户端和NEA服务器之间进行无限次的往返。
Requirement C-2 says:
要求C-2规定：
C-2 NEA protocols SHOULD provide a way for both the NEA Client and the NEA Server to initiate a posture assessment or reassessment as needed.
C-2 NEA协议应为NEA客户端和NEA服务器提供一种方式，以便根据需要启动姿势评估或重新评估。
PA-TNC meets this requirement. PA-TNC is designed to work whether the NEA Client or the NEA Server initiates a posture assessment or reassessment.
PA-TNC符合这一要求。PA-TNC设计用于在NEA客户端或NEA服务器启动姿势评估或重新评估时工作。
Requirement C-3 says:
要求C-3规定：
C-3 NEA protocols including security capabilities MUST be capable of protecting against active and passive attacks by intermediaries and endpoints including prevention from replay-based attacks.
C-3 NEA协议（包括安全功能）必须能够防止中介和端点的主动和被动攻击，包括防止基于重播的攻击。
Security for PA-TNC messages being sent over the network is provided through PT protocol security. Therefore, PA-TNC does not include any security capabilities. Since this requirement only applies to NEA protocols "including security capabilities", this specification is not subject to this requirement (see section 5.2).
通过PT协议安全性为通过网络发送的PA-TNC消息提供安全性。因此，PA-TNC不包括任何安全功能。由于本要求仅适用于“包括安全功能”的NEA协议，因此本规范不受本要求的约束（见第5.2节）。
Requirement C-4 says:
要求C-4规定：
C-4 The PA and PB protocols MUST be capable of operating over any PT protocol. For example, the PB protocol must provide a transport-independent interface allowing the PA protocol to operate without change across a variety of network protocol environments (e.g., EAP/802.1X, PANA, TLS and IKE/IPsec).
C-4 PA和PB协议必须能够在任何PT协议上运行。例如，PB协议必须提供一个独立于传输的接口，允许PA协议在各种网络协议环境（例如EAP/802.1X、PANA、TLS和IKE/IPsec）中运行而不发生变化。
PA-TNC meets this requirement. PA-TNC can operate over any PT protocol that meets the requirements for PT stated in the NEA Requirements document. PA-TNC does not have any dependencies on specific details of the underlying PT protocol.
PA-TNC符合这一要求。PA-TNC可在满足NEA要求文件中规定的PT要求的任何PT协议上运行。PA-TNC不依赖于基础PT协议的具体细节。
Requirement C-5 says:
要求C-5规定：
C-5 The selection process for NEA protocols MUST evaluate and prefer the reuse of existing open standards that meet the requirements before defining new ones. The goal of NEA is not to create additional alternative protocols where acceptable solutions already exist.
C-5在定义新的开放标准之前，NEA协议的选择过程必须评估并优先重用满足要求的现有开放标准。NEA的目标不是在已经存在可接受解决方案的情况下创建其他替代协议。
Based on this requirement, PA-TNC should receive a strong preference. PA-TNC is equivalent with IF-M 1.0, an open TCG specification. Other specifications from TCG and other groups are also under development based on the IF-M 1.0 specification. Selecting PA-TNC as the basis for the PA protocol will ensure compatibility with IF-M 1.0, with these other specifications, and with their implementations.
基于这一要求，PA-TNC应受到强烈的青睐。PA-TNC与开放式TCG规范IF-M 1.0等效。TCG和其他团队的其他规范也正在基于IF-M 1.0规范进行开发。选择PA-TNC作为PA协议的基础将确保与IF-M 1.0、这些其他规范及其实现的兼容性。
Requirement C-6 says:
要求C-6规定：
C-6 NEA protocols MUST be highly scalable; the protocols MUST support many Posture Collectors on a large number of NEA Clients to be assessed by numerous Posture Validators residing on multiple NEA Servers.
C-6 NEA协议必须具有高度可扩展性；协议必须支持大量NEA客户端上的多个姿态采集器，这些客户端将由驻留在多个NEA服务器上的多个姿态验证器进行评估。
PA-TNC meets this requirement. PA-TNC supports an unlimited number of Posture Collectors, Posture Validators, NEA Clients, and NEA Servers. It also is quite scalable in many other aspects as well. A PA-TNC message can contain up to 2^32-1 octets and about 2^28 PA-TNC attributes. Each organization with an SMI Private Enterprise Number is entitled to define up to 2^32 vendor-specific PA-TNC Attribute Types, 2^16 vendor-specific PA-TNC Product IDs, and 2^32 vendor-
PA-TNC符合这一要求。PA-TNC支持无限数量的姿态采集器、姿态验证器、NEA客户端和NEA服务器。它在许多其他方面也具有相当的可扩展性。PA-TNC消息最多可包含2^32-1个八位字节和约2^28个PA-TNC属性。每个拥有SMI私有企业编号的组织有权定义多达2^32个特定于供应商的PA-TNC属性类型、2^16个特定于供应商的PA-TNC产品ID和2^32个供应商-
specific PA-TNC Error Codes. Each attribute can contain almost 2^32 octets. It is generally not advisable or necessary to send this much data in a NEA assessment, but still PA-TNC is highly scalable and meets requirement C-6 easily.
特定PA-TNC错误代码。每个属性可以包含几乎2^32个八位字节。在NEA评估中发送这么多数据通常是不可取或不必要的，但PA-TNC仍然具有高度的可扩展性，并且很容易满足C-6的要求。
Requirement C-7 says:
要求C-7规定：
C-7 The protocols MUST support efficient transport of a large number of attribute messages between the NEA Client and the NEA Server.
C-7协议必须支持在NEA客户端和NEA服务器之间高效传输大量属性消息。
PA-TNC meets this requirement. Each PA-TNC message can contain about 2^28 PA-TNC attributes. PA-TNC supports up to 2^32 round trips in a session so the maximum number of attribute messages that can be sent in a single session is actually about 2^50. However, it is generally inadvisable and unnecessary to send a large number of messages in a NEA assessment. As for efficiency, PA-TNC adds only 12 octets of overhead per attribute and 8 octets per message (which is negligible on a per-attribute basis).
PA-TNC符合这一要求。每个PA-TNC消息可以包含大约2^28个PA-TNC属性。PA-TNC在一个会话中最多支持2^32次往返，因此在单个会话中可以发送的属性消息的最大数量实际上约为2^50。然而，在NEA评估中发送大量信息通常是不可取的，也没有必要的。至于效率，PA-TNC只增加了每个属性12个八位字节的开销和每个消息8个八位字节的开销（这在每个属性的基础上可以忽略不计）。
Requirement C-8 says:
要求C-8规定：
C-8 NEA protocols MUST operate efficiently over low bandwidth or high latency links.
C-8 NEA协议必须在低带宽或高延迟链路上高效运行。
PA-TNC meets this requirement. A PA-TNC exchange is envisioned (based on current deployment experience) to involve one or two round trips with less than 500 octets of PA-TNC messages. Of course, use of vendor-specific PA-TNC attribute types could expand the assessment. However, PA-TNC itself imposes an overhead of only 8 octets per PA-TNC message and 12 octets per attribute.
PA-TNC符合这一要求。根据目前的部署经验，预计PA-TNC交换将涉及一次或两次往返，其中PA-TNC消息少于500个八位组。当然，使用特定于供应商的PA-TNC属性类型可以扩大评估范围。然而，PA-TNC本身的开销仅为每个PA-TNC消息8个八位字节，每个属性12个八位字节。
Requirement C-9 says:
要求C-9规定：
C-9 For any strings intended for display to a user, the protocols MUST support adapting these strings to the user's language preferences.
C-9对于打算向用户显示的任何字符串，协议必须支持根据用户的语言偏好调整这些字符串。
PA-TNC meets this requirement. The only field included in a PB-TNC attribute for display to the user includes a language tag that could be selected based upon the user's PB-TNC negotiated preferred language for the assessment (see section 4.10 of the PB-TNC
PA-TNC符合这一要求。PB-TNC属性中用于向用户显示的唯一字段包括一个语言标签，该标签可根据用户的PB-TNC协商的评估首选语言进行选择（见PB-TNC第4.10节）
specification). With this exception, all of the strings in the standard PA-TNC attributes are intended for logging and programmatic comparisons.
规格）。除此之外，标准PA-TNC属性中的所有字符串都用于日志记录和编程比较。
If any vendor-specific PA-TNC attribute types or future IETF Standard PA-TNC Attribute Types include strings that are intended for display to a user, they should be translated to the user's preferred language. The Posture Broker Server will need to expose the user's preferences to the Posture Validators through whatever API or protocol is used to connect those components. However, that is all out of scope for this specification.
如果任何特定于供应商的PA-TNC属性类型或未来的IETF标准PA-TNC属性类型包含用于向用户显示的字符串，则应将其翻译为用户的首选语言。姿态代理服务器将需要通过用于连接这些组件的API或协议向姿态验证器公开用户的首选项。然而，这完全超出了本规范的范围。
Requirement C-10 says:
要求C-10规定：
C-10 NEA protocols MUST support encoding of strings in UTF-8 format.
C-10 NEA协议必须支持UTF-8格式的字符串编码。
PA-TNC meets this requirement. All strings in the PA-TNC protocol are encoded in UTF-8 format. This allows the protocol to support a wide range of languages efficiently.
PA-TNC符合这一要求。PA-TNC协议中的所有字符串都以UTF-8格式编码。这使得协议能够有效地支持多种语言。
Requirement C-11 says:
要求C-11规定：
C-11 Due to the potentially different transport characteristics provided by the underlying candidate PT protocols, the NEA Client and NEA Server MUST be capable of becoming aware of and adapting to the limitations of the available PT protocol. For example, some PT protocol characteristics that might impact the operation of PA and PB include restrictions on which end can initiate a NEA connection, maximum data size in a message or full assessment, upper bound on number of round trips, and ordering (duplex) of messages exchanged. The selection process for the PT protocols MUST consider the limitations the candidate PT protocol would impose upon the PA and PB protocols.
C-11由于潜在候选PT协议提供的潜在不同传输特性，NEA客户端和NEA服务器必须能够意识到并适应可用PT协议的限制。例如，可能影响PA和PB操作的一些PT协议特征包括限制哪一端可以启动NEA连接、消息中的最大数据大小或完全评估、往返次数上限以及交换消息的顺序（双工）。PT协议的选择过程必须考虑候选PT协议对PA和PB协议施加的限制。
PA-TNC meets this requirement. The design of the PA-TNC protocol emphasizes efficient transport of information in order to maximize its usability in constrained PT environments. Local APIs could allow Posture Collectors and Posture Validators to discover when they are operating in a less constrained deployment and then make use of more verbose attributes. Similarly, Posture Collectors could choose not to send or use smaller attributes (including assertions from previous assessments) when faced with a very constrained network connection.
PA-TNC符合这一要求。PA-TNC协议的设计强调信息的高效传输，以最大限度地提高其在受限PT环境中的可用性。本地API允许姿态采集器和姿态验证器发现它们何时在约束较少的部署中运行，然后使用更详细的属性。类似地，当面临非常受限的网络连接时，姿态收集器可以选择不发送或使用较小的属性（包括以前评估中的断言）。
Requirement PA-1 says:
要求PA-1规定：
PA-1 The PA protocol MUST support communication of an extensible set of NEA standards-defined attributes. These attributes will be uniquely identifiable from non-standard attributes.
PA-1 PA协议必须支持一组可扩展的NEA标准定义属性的通信。这些属性将与非标准属性唯一可识别。
PA-TNC meets this requirement. Each attribute is identified with a PA-TNC Attribute Vendor ID and a PA-TNC Attribute Type. IETF Standard PA-TNC Attribute Types use a vendor ID of zero (0), in contrast with vendor-specific PA-TNC Attribute Types, which will use the vendor's SMI Private Enterprise Number as the vendor ID. The IANA will maintain a registry of PA-TNC Attribute Types with new values added by Expert Review with Specification Required, as described in the IANA Considerations section of this specification. Thus, the set of standard attribute types is extensible, but all standard attribute types are uniquely identifiable.
PA-TNC符合这一要求。每个属性都由PA-TNC属性供应商ID和PA-TNC属性类型标识。IETF标准PA-TNC属性类型使用零（0）的供应商ID，与特定于供应商的PA-TNC属性类型不同，后者将使用供应商的SMI私有企业号作为供应商ID。IANA将维护PA-TNC属性类型的注册表，并通过专家评审按要求添加新值，如本规范IANA注意事项部分所述。因此，标准属性类型集是可扩展的，但所有标准属性类型都是唯一可标识的。
Requirement PA-2 says:
要求PA-2规定：
PA-2 The PA protocol MUST support communication of an extensible set of vendor-specific attributes. These attributes will be segmented into uniquely identifiable vendor-specific namespaces.
PA-2 PA协议必须支持一组可扩展的供应商特定属性的通信。这些属性将被分割为唯一可识别的特定于供应商的名称空间。
PA-TNC meets this requirement. Each attribute is identified with a PA-TNC Attribute Vendor ID and a PA-TNC Attribute Type. Vendor-defined PA-TNC Attribute Types use the vendor's SMI Private Enterprise Number as the PA-TNC Attribute Vendor ID. Each vendor can define up to 2^32 PA-TNC Attribute Types, using its own internal processes to manage its set of attribute types.
PA-TNC符合这一要求。每个属性都由PA-TNC属性供应商ID和PA-TNC属性类型标识。供应商定义的PA-TNC属性类型使用供应商的SMI私有企业编号作为PA-TNC属性供应商ID。每个供应商最多可以定义2^32个PA-TNC属性类型，使用其自己的内部流程来管理其属性类型集。
The IANA is not involved, other than the initial assignment of the vendor's SMI Private Enterprise Number. Thus, the set of vendor-specific attributes is segmented into uniquely identifiable vendor-specific namespaces.
IANA不参与，但供应商SMI私有企业编号的初始分配除外。因此，特定于供应商的属性集被分割为唯一可识别的特定于供应商的名称空间。
Requirement PA-3 says:
要求PA-3规定：
PA-3 The PA protocol MUST enable a Posture Validator to make one or more requests for attributes from a Posture Collector within a single assessment. This enables the Posture Validator to reassess the posture of a particular endpoint feature or to request additional posture including from other parts of the endpoint.
PA-3 PA协议必须允许姿势验证器在一次评估中从姿势收集器发出一个或多个属性请求。这使得姿势验证器能够重新评估特定端点特征的姿势，或者请求额外的姿势，包括来自端点其他部分的姿势。
PA-TNC meets this requirement. The Attribute Request attribute type is an IETF Standard PA-TNC Attribute Type that permits a Posture Validator to send to one or more Posture Collectors a request for one or more attributes. This attribute may be sent at any point in the posture assessment process and may in fact be sent more than once if the Posture Validator needs to first determine the type of operating system and then request certain attributes specific to that operating system, for example.
PA-TNC符合这一要求。属性请求属性类型是IETF标准PA-TNC属性类型，允许姿势验证器向一个或多个姿势收集器发送一个或多个属性请求。例如，如果姿势验证器需要首先确定操作系统的类型，然后请求特定于该操作系统的某些属性，则该属性可以在姿势评估过程中的任何点发送，并且实际上可以发送不止一次。
Requirement PA-4 says:
要求PA-4规定：
PA-4 The PA protocol MUST be capable of returning attributes from a Posture Validator to a Posture Collector. For example, this might enable the Posture Collector to learn the specific reason for a failed assessment and to aid in remediation and notification of the system owner.
PA-4 PA协议必须能够将属性从姿势验证器返回到姿势收集器。例如，这可能使姿态收集器能够了解评估失败的具体原因，并帮助补救和通知系统所有者。
PA-TNC meets this requirement. A Posture Validator can easily send attributes to one or more Posture Collectors.
PA-TNC符合这一要求。姿势验证器可以轻松地将属性发送到一个或多个姿势收集器。
Requirement PA-5 says:
要求PA-5规定：
PA-5 The PA protocol SHOULD provide authentication, integrity, and confidentiality of attributes communicated between a Posture Collector and Posture Validator. This enables end-to-end security across a NEA deployment that might involve traversal of several systems or trust boundaries.
PA-5 PA协议应提供姿势收集器和姿势验证器之间通信的属性的身份验证、完整性和机密性。这使得跨NEA部署的端到端安全性成为可能，NEA部署可能涉及跨越多个系统或信任边界。
PA-TNC does not include an explicit PA-level security mechanism but does lay a foundation allowing attribute-level security protections to be added later. As an existence proof, the NEA working group considered an Internet-Draft proposal capable of encapsulating PA attributes within a Cryptographic Message Syntax (CMS) security wrapper in a new attribute type. This proposal offered the protections described in this requirement. However, the NEA WG decided that the use cases in scope for the working group did not require PA-level security. The use cases involving PA message traversal of multiple systems or trust boundaries were considered out of scope; therefore, a Posture Validator to Posture Collector end-to-end security protection was considered not to be required.
PA-TNC不包括显式PA级安全机制，但确实为以后添加属性级安全保护打下基础。作为存在性证明，NEA工作组审议了一份能够将PA属性封装在加密消息语法（CMS）安全包装中的互联网提案草案，该草案采用了一种新的属性类型。本建议书提供了本要求中所述的保护。然而，NEA工作组决定，工作组范围内的用例不需要PA级安全性。涉及多个系统的PA消息遍历或信任边界的用例被认为超出了范围；因此，姿态验证器到姿态收集器端到端安全保护被认为是不需要的。
Instead, PA-TNC attributes are protected by the PT layer authentication, integrity, and confidentiality support. This protects the attributes communicated between the Posture Transport
相反，PA-TNC属性受PT层身份验证、完整性和机密性支持的保护。这将保护姿态传输之间通信的属性
Client and Posture Transport Server. Because the Posture Collector is in the same address space as the Posture Broker Client and Posture Transport Client and the Posture Validator is in the same address space as the Posture Broker Server and Posture Transport Server, the underlying broker and transport components are deemed trusted with respect to not tampering with the PA messages (see trust model in section 5.1 for details). Encrypting the PA-TNC messages would not prevent a hostile broker or transport component from attacking the messages.
客户端和传输服务器。由于姿态采集器与姿态代理客户端和姿态传输客户端位于同一地址空间，而姿态验证器与姿态代理服务器和姿态传输服务器位于同一地址空间，因此就不篡改PA消息而言，底层代理和传输组件被视为可信的（有关详细信息，请参阅第5.1节中的信任模型）。加密PA-TNC消息不会阻止恶意代理或传输组件攻击消息。
Requirement PA-6 says:
要求PA-6规定：
PA-6 The PA protocol MUST be capable of carrying attributes that contain non-binary and binary data including encrypted content.
PA-6 PA协议必须能够承载包含非二进制和二进制数据（包括加密内容）的属性。
PA-TNC meets this requirement. PA-TNC attributes can contain non-binary and binary data including encrypted content. For examples, see the attribute type definitions contained in this specification.
PA-TNC符合这一要求。PA-TNC属性可以包含非二进制和二进制数据，包括加密内容。有关示例，请参见本规范中包含的属性类型定义。
Authors' Addresses
作者地址
Paul Sangster Symantec Corporation 6825 Citrine Drive Carlsbad, CA 92009 USA EMail: Paul_Sangster@symantec.com
Paul Sangster Symantec Corporation 6825 Citrine Drive Carlsbad，CA 92009美国电子邮件：Paul_Sangster@symantec.com
Kaushik Narayan Cisco Systems Inc. 10 West Tasman Drive San Jose, CA 95134 USA EMail: kaushik@cisco.com
Kaushik Narayan Cisco Systems Inc.美国加利福尼亚州圣何塞西塔斯曼大道10号邮编95134电子邮件：kaushik@cisco.com