Network Working Group P. Sangster
Request for Comments: 5209 Symantec
Category: Informational H. Khosravi
Intel
M. Mani
Avaya
K. Narayan
Cisco Systems
J. Tardo
Nevis Networks
June 2008
Network Working Group P. Sangster
Request for Comments: 5209 Symantec
Category: Informational H. Khosravi
Intel
M. Mani
Avaya
K. Narayan
Cisco Systems
J. Tardo
Nevis Networks
June 2008
Network Endpoint Assessment (NEA): Overview and Requirements
网络端点评估（NEA）：概述和要求
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
This document defines the problem statement, scope, and protocol requirements between the components of the NEA (Network Endpoint Assessment) reference model. NEA provides owners of networks (e.g., an enterprise offering remote access) a mechanism to evaluate the posture of a system. This may take place during the request for network access and/or subsequently at any time while connected to the network. The learned posture information can then be applied to a variety of compliance-oriented decisions. The posture information is frequently useful for detecting systems that are lacking or have out-of-date security protection mechanisms such as: anti-virus and host-based firewall software. In order to provide context for the requirements, a reference model and terminology are introduced.
本文件定义了NEA（网络端点评估）参考模型组件之间的问题陈述、范围和协议要求。NEA为网络所有者（例如，提供远程访问的企业）提供了一种评估系统状态的机制。这可能发生在网络访问请求期间和/或随后连接到网络时的任何时间。然后，学习到的姿势信息可以应用于各种面向合规性的决策。姿态信息通常用于检测缺乏或具有过时安全保护机制的系统，例如：防病毒和基于主机的防火墙软件。为了为需求提供上下文，引入了参考模型和术语。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
2. Terminology .....................................................5
3. Applicability ...................................................7
3.1. Scope ......................................................7
3.2. Applicability of Environments ..............................8
4. Problem Statement ...............................................9
5. Reference Model ................................................10
5.1. NEA Client and Server .....................................12
5.1.1. NEA Client .........................................12
5.1.1.1. Posture Collector .........................12
5.1.1.2. Posture Broker Client .....................14
5.1.1.3. Posture Transport Client ..................15
5.1.2. NEA Server .........................................15
5.1.2.1. Posture Validator .........................15
5.1.2.2. Posture Broker Server .....................17
5.1.2.3. Posture Transport Server ..................18
5.2. Protocols .................................................18
5.2.1. Posture Attribute Protocol (PA) ....................18
5.2.2. Posture Broker Protocol (PB) .......................19
5.2.3. Posture Transport Protocol (PT) ....................19
5.3. Attributes ................................................20
5.3.1. Attributes Normally Sent by NEA Client: ............21
5.3.2. Attributes Normally Sent by NEA Server: ............21
6. Use Cases ......................................................22
6.1. Initial Assessment ........................................22
6.1.1. Triggered by Network Connection or Service
Request ............................................22
6.1.1.1. Example ...................................23
6.1.1.2. Possible Flows and Protocol Usage .........23
6.1.1.3. Impact on Requirements ....................25
6.1.2. Triggered by Endpoint ..............................25
6.1.2.1. Example ...................................25
6.1.2.2. Possible Flows and Protocol Usage .........26
6.1.2.3. Impact on Requirements ....................28
6.2. Posture Reassessment ......................................28
6.2.1. Triggered by NEA Client ............................28
6.2.1.1. Example ...................................28
6.2.1.2. Possible Flows & Protocol Usage ...........29
6.2.1.3. Impact on Requirements ....................30
6.2.2. Triggered by NEA Server ............................30
6.2.2.1. Example ...................................30
6.2.2.2. Possible Flows and Protocol Usage .........31
6.2.2.3. Impact on Requirements ....................33
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
2. Terminology .....................................................5
3. Applicability ...................................................7
3.1. Scope ......................................................7
3.2. Applicability of Environments ..............................8
4. Problem Statement ...............................................9
5. Reference Model ................................................10
5.1. NEA Client and Server .....................................12
5.1.1. NEA Client .........................................12
5.1.1.1. Posture Collector .........................12
5.1.1.2. Posture Broker Client .....................14
5.1.1.3. Posture Transport Client ..................15
5.1.2. NEA Server .........................................15
5.1.2.1. Posture Validator .........................15
5.1.2.2. Posture Broker Server .....................17
5.1.2.3. Posture Transport Server ..................18
5.2. Protocols .................................................18
5.2.1. Posture Attribute Protocol (PA) ....................18
5.2.2. Posture Broker Protocol (PB) .......................19
5.2.3. Posture Transport Protocol (PT) ....................19
5.3. Attributes ................................................20
5.3.1. Attributes Normally Sent by NEA Client: ............21
5.3.2. Attributes Normally Sent by NEA Server: ............21
6. Use Cases ......................................................22
6.1. Initial Assessment ........................................22
6.1.1. Triggered by Network Connection or Service
Request ............................................22
6.1.1.1. Example ...................................23
6.1.1.2. Possible Flows and Protocol Usage .........23
6.1.1.3. Impact on Requirements ....................25
6.1.2. Triggered by Endpoint ..............................25
6.1.2.1. Example ...................................25
6.1.2.2. Possible Flows and Protocol Usage .........26
6.1.2.3. Impact on Requirements ....................28
6.2. Posture Reassessment ......................................28
6.2.1. Triggered by NEA Client ............................28
6.2.1.1. Example ...................................28
6.2.1.2. Possible Flows & Protocol Usage ...........29
6.2.1.3. Impact on Requirements ....................30
6.2.2. Triggered by NEA Server ............................30
6.2.2.1. Example ...................................30
6.2.2.2. Possible Flows and Protocol Usage .........31
6.2.2.3. Impact on Requirements ....................33
7. Requirements ...................................................34
7.1. Common Protocol Requirements ..............................34
7.2. Posture Attribute (PA) Protocol Requirements ..............35
7.3. Posture Broker (PB) Protocol Requirements .................36
7.4. Posture Transport (PT) Protocol Requirements ..............38
8. Security Considerations ........................................38
8.1. Trust .....................................................39
8.1.1. Endpoint ...........................................40
8.1.2. Network Communications .............................41
8.1.3. NEA Server .........................................42
8.2. Protection Mechanisms at Multiple Layers ..................43
8.3. Relevant Classes of Attack ................................43
8.3.1. Man-in-the-Middle (MITM) ...........................44
8.3.2. Message Modification ...............................45
8.3.3. Message Replay or Attribute Theft ..................45
8.3.4. Other Types of Attack ..............................46
9. Privacy Considerations .........................................46
9.1. Implementer Considerations ................................47
9.2. Minimizing Attribute Disclosure ...........................49
10. References ....................................................50
10.1. Normative References .....................................50
10.2. Informative References ...................................50
11. Acknowledgments ...............................................51
7. Requirements ...................................................34
7.1. Common Protocol Requirements ..............................34
7.2. Posture Attribute (PA) Protocol Requirements ..............35
7.3. Posture Broker (PB) Protocol Requirements .................36
7.4. Posture Transport (PT) Protocol Requirements ..............38
8. Security Considerations ........................................38
8.1. Trust .....................................................39
8.1.1. Endpoint ...........................................40
8.1.2. Network Communications .............................41
8.1.3. NEA Server .........................................42
8.2. Protection Mechanisms at Multiple Layers ..................43
8.3. Relevant Classes of Attack ................................43
8.3.1. Man-in-the-Middle (MITM) ...........................44
8.3.2. Message Modification ...............................45
8.3.3. Message Replay or Attribute Theft ..................45
8.3.4. Other Types of Attack ..............................46
9. Privacy Considerations .........................................46
9.1. Implementer Considerations ................................47
9.2. Minimizing Attribute Disclosure ...........................49
10. References ....................................................50
10.1. Normative References .....................................50
10.2. Informative References ...................................50
11. Acknowledgments ...............................................51
Endpoints connected to a network may be exposed to a wide variety of threats. Some protection against these threats can be provided by ensuring that endpoints conform to security policies. Therefore, the intent of NEA is to assess these endpoints to determine their compliance with security policies so that corrective measures can be provided before they are exposed to those threats. For example, if a system is determined to be out of compliance because it is lacking proper defensive mechanisms such as host-based firewalls, anti-virus software, or the absence of critical security patches, the NEA protocols provide a mechanism to detect this fact and indicate appropriate remediation actions to be taken. Note that an endpoint that is deemed compliant may still be vulnerable to threats that may exist on the network.
连接到网络的端点可能面临各种各样的威胁。通过确保端点符合安全策略，可以提供一些针对这些威胁的保护。因此，NEA的目的是评估这些端点，以确定它们是否符合安全策略，以便在它们暴露于这些威胁之前提供纠正措施。例如，如果系统因缺乏适当的防御机制（如基于主机的防火墙、防病毒软件或缺少关键安全补丁）而被确定为不合规，NEA协议将提供一种机制来检测这一事实，并指示要采取的适当补救措施。请注意，被视为兼容的端点可能仍然容易受到网络上可能存在的威胁的攻击。
NEA typically involves the use of special client software running on the requesting endpoint that observes and reports on the configuration of the system to the network infrastructure. The infrastructure has corresponding validation software that is capable of comparing the endpoint's configuration information with network compliance policies and providing the result to appropriate authorization entities that make decisions about network and application access. Some endpoints may be incapable of running the
NEA通常涉及使用在请求端点上运行的特殊客户端软件，该软件观察并向网络基础设施报告系统配置。基础设施具有相应的验证软件，该软件能够将端点的配置信息与网络合规性策略进行比较，并将结果提供给做出网络和应用程序访问决策的适当授权实体。某些终结点可能无法运行
NEA Client software (e.g., printer) or be unwilling to share information about their configuration. This situation is outside the scope of NEA and is subject to local policies.
NEA客户端软件（如打印机）或不愿意共享其配置信息。这种情况不属于国家能源局的范围，并受当地政策的制约。
The result of an endpoint assessment may influence an access decision that is provisioned to the enforcement mechanisms on the network and/or endpoint requesting access. While the NEA Working Group recognizes there may be a link between an assessment and the enforcement of a resulting access decision, the mechanisms and protocols for enforcement are not in scope for this specification.
端点评估的结果可能影响提供给网络上的实施机制和/或请求访问的端点的访问决策。虽然NEA工作组认识到评估和执行结果访问决定之间可能存在联系，但执行机制和协议不在本规范的范围内。
Architectures, similar to NEA, have existed in the industry for some time and are present in shipping products, but do not offer adequate interoperability. Some examples of such architectures include: Trusted Computing Group's Trusted Network Connect [TNC], Microsoft's Network Access Protection [NAP], and Cisco's Cisco Network Admission Control [CNAC]. These technologies assess the software and/or hardware configuration of endpoint devices for the purposes of monitoring or enforcing compliance to an organization's policy.
与NEA类似的体系结构在业界已经存在了一段时间，并出现在运输产品中，但没有提供足够的互操作性。此类架构的一些示例包括：可信计算集团的可信网络连接[TNC]、微软的网络访问保护[NAP]和思科的思科网络准入控制[CNAC]。这些技术评估终端设备的软件和/或硬件配置，以监控或强制遵守组织的策略。
The NEA Working Group is developing standard protocols that can be used to communicate compliance information between a NEA Client and a NEA Server. This document provides the context for NEA including: terminology, applicability, problem statement, reference model, and use cases. It then identifies requirements for the protocols used to communicate between a NEA Client and NEA server. Finally, this document discusses some potential security and privacy considerations with the use of NEA. The majority of this specification provides informative text describing the context of NEA.
NEA工作组正在开发标准协议，可用于在NEA客户端和NEA服务器之间传递法规遵从性信息。本文档提供了NEA的上下文，包括：术语、适用性、问题陈述、参考模型和用例。然后确定用于NEA客户端和NEA服务器之间通信的协议要求。最后，本文档讨论了使用NEA时的一些潜在安全和隐私注意事项。本规范的大部分内容提供了描述NEA上下文的信息性文本。
Use of each capitalized word within a sentence or phrase carries the following meaning during the NEA WG's protocol selection process:
在NEA工作组的方案选择过程中，在句子或短语中使用每个大写单词具有以下含义：
MUST - indicates an absolute requirement
必须-表示绝对要求
MUST NOT - indicates something absolutely prohibited
不得-表示绝对禁止的内容
SHOULD - indicates a strong recommendation of a desired result
应该-表示对预期结果的强烈建议
SHOULD NOT - indicates a strong recommendation against a result
不应该-表示强烈反对结果的建议
MAY - indicates a willingness to allow an optional outcome
可能-表示允许可选结果的意愿
Lower case use of "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" carry their normal meaning and are not subject to these definitions.
“必须”、“不得”、“应该”、“不应该”和“可以”的小写用法具有其正常含义，不受这些定义的约束。
This section defines a set of terms used throughout this document. In some cases these terms have been used in other contexts with different meanings so this section attempts to describe each term's meaning with respect to the NEA WG activities.
本节定义了本文件中使用的一组术语。在某些情况下，这些术语已在其他具有不同含义的上下文中使用，因此本节试图描述与NEA WG活动相关的每个术语的含义。
Assessment - The process of collecting posture for a set of capabilities on the endpoint (e.g., host-based firewall) such that the appropriate validators may evaluate the posture against compliance policy.
评估-收集端点（例如，基于主机的防火墙）上一组功能的态势的过程，以便适当的验证器可以根据合规性策略评估态势。
Assertion Attributes - Attributes that include reusable information about the success of a prior assessment of the endpoint. This could be used to optimize subsequent assessments by avoiding a full posture reassessment. For example, this classification of attribute might be issued specifically to a particular endpoint, dated and signed by the NEA Server allowing that endpoint to reuse it for a time period to assert compliance to a set of policies. The NEA Server might accept this in lieu of obtaining posture information.
断言属性—包含有关端点先前评估成功的可重用信息的属性。这可以通过避免全面姿势重新评估来优化后续评估。例如，该属性分类可能专门发布给特定端点，由NEA服务器注明日期并签名，允许该端点在一段时间内重复使用该属性，以确保符合一组策略。NEA服务器可能会接受这一点，而不是获取姿势信息。
Attribute - Data element including any requisite meta-data describing an observed, expected, or the operational status of an endpoint feature (e.g., anti-virus software is currently in use). Attributes are exchanged as part of the NEA protocols (see section 5.2). NEA recognizes a variety of usage scenarios where the use of an attribute in a particular type of message could indicate:
属性-数据元素，包括描述观察到的、预期的或端点功能运行状态的任何必要元数据（例如，当前正在使用的防病毒软件）。属性作为NEA协议的一部分进行交换（见第5.2节）。NEA认识到各种使用场景，其中在特定类型的消息中使用属性可能表明：
o previously assessed status (Assertion Attributes),
o 先前评估的状态（断言属性），
o observed configuration or property (Posture Attributes),
o 观察到的配置或属性（姿势属性），
o request for configuration or property information (Request Attributes),
o 请求配置或属性信息（请求属性），
o assessment decision (Result Attributes), or
o 评估决策（结果属性），或
o repair instructions (Remediation Attributes).
o 修复说明（修复属性）。
The NEA WG will standardize a subset of the attribute namespace known as standard attributes. Those attributes not standardized are referred to in this specification as vendor-specific.
NEA WG将标准化称为标准属性的属性名称空间的子集。这些未标准化的属性在本规范中称为特定于供应商的属性。
Dialog - Sequence of request/response messages exchanged.
对话框-交换的请求/响应消息的顺序。
Endpoint - Any computing device that can be connected to a network. Such devices normally are associated with a particular link layer address before joining the network and potentially an IP address once on the network. This includes: laptops, desktops, servers, cell phones, or any device that may have an IP address.
端点-任何可以连接到网络的计算设备。此类设备通常在加入网络之前与特定链路层地址相关联，并且一旦在网络上，就可能与IP地址相关联。这包括：笔记本电脑、台式机、服务器、手机或任何可能具有IP地址的设备。
Message - Self contained unit of communication between the NEA Client and Server. For example, a posture attribute message might carry a set of attributes describing the configuration of the anti-virus software on an endpoint.
消息-NEA客户端和服务器之间的独立通信单元。例如，姿态属性消息可能包含一组描述端点上防病毒软件配置的属性。
Owner - the role of an entity who is the legal, rightful possessor of an asset (e.g., endpoint). The owner is entitled to maintain control over the policies enforced on the device even if the asset is not within the owner's possession. The owner may permit user override or augmentation of control policies or may choose to not assert any policies limiting use of asset.
所有者-作为资产（如端点）合法合法所有者的实体的角色。即使资产不在所有者拥有范围内，所有者也有权保持对设备上强制执行的政策的控制。所有者可以允许用户覆盖或增加控制策略，或者可以选择不主张任何限制资产使用的策略。
Posture - Configuration and/or status of hardware or software on an endpoint as it pertains to an organization's security policy.
姿态—端点上硬件或软件的配置和/或状态，因为它与组织的安全策略有关。
Posture Attributes - Attributes describing the configuration or status (posture) of a feature of the endpoint. For example, a Posture Attribute might describe the version of the operating system installed on the system.
姿态属性-描述端点特征的配置或状态（姿态）的属性。例如，姿态属性可能描述系统上安装的操作系统的版本。
Request Attributes - Attributes sent by a NEA Server identifying the posture information requested from the NEA Client. For example, a Request Attribute might be an attribute included in a request message from the NEA Server that is asking for the version information for the operating system on the endpoint.
请求属性-NEA服务器发送的属性，用于识别从NEA客户端请求的姿势信息。例如，请求属性可能是来自NEA服务器的请求消息中包含的属性，该服务器正在请求端点上操作系统的版本信息。
Remediation Attributes - Attributes containing the remediation instructions for how to bring an endpoint into compliance with one or more policies. The NEA WG will not define standard remediation attributes, but this specification does describe where they are used within the reference model and protocols.
修正属性—包含有关如何使端点符合一个或多个策略的修正说明的属性。NEA工作组不会定义标准补救属性，但本规范确实描述了在参考模型和协议中使用这些属性的位置。
Result Attributes - Attributes describing whether the endpoint is in compliance with NEA policy. The Result Attribute is created by the NEA Server normally at the conclusion of the assessment to indicate whether or not the endpoint was considered compliant. More than one of these attributes may be used allowing for more granular feature level decisions to be communicated in addition to an overall, global assessment decision.
结果属性-描述端点是否符合NEA策略的属性。结果属性通常由NEA服务器在评估结束时创建，以指示端点是否被视为符合要求。除了整体、全局评估决策外，还可以使用这些属性中的一个以上，以便传达更细粒度的特征级决策。
Session - Stateful connection capable of carrying multiple message exchanges associated with (an) assessment(s) of a particular endpoint. This document defines the term session at a conceptual level and does not describe the properties of the session or specify requirements for the NEA protocols to manage these sessions.
会话-有状态连接，能够承载与特定端点的评估相关联的多个消息交换。本文件在概念层面上定义了会话一词，未描述会话的属性，也未规定管理这些会话的NEA协议要求。
User - Role of a person that is making use of the services of an endpoint. The user may not own the endpoint so he or she might need to operate within the acceptable use constraints defined by the endpoint's owner. For example, an enterprise employee might be a user of a computer provided by the enterprise (owner) for business purposes.
用户-使用端点服务的人员的角色。用户可能不拥有端点，因此他或她可能需要在端点所有者定义的可接受使用约束内操作。例如，企业员工可能是企业（所有者）出于业务目的提供的计算机的用户。
This section discusses the scope of the technologies being standardized and the network environments where it is envisioned that the NEA technologies might be applicable.
本节讨论正在标准化的技术的范围，以及预期NEA技术可能适用的网络环境。
The priority of the NEA Working Group is to develop standard protocols at the higher layers in the reference model (see section 5): the Posture Attribute protocol (PA) and the Posture Broker protocol (PB). PA and PB will be designed to be carried over a variety of lower layer transport (PT) protocols. The NEA WG will identify standard PT protocol(s) that are mandatory to implement. PT protocols may be defined in other WGs because the requirements may not be specific to NEA. When used with a standard PT protocol (e.g., Extensible Authentication Protocol (EAP), Transport Layer Security (TLS) [TLS]), the PA and PB protocols will allow interoperability between a NEA Client from one vendor and a NEA Server from another. This specification will not focus on the other interfaces between the functional components of the NEA reference model nor requirements on their internals. Any discussion of these aspects is included to provide context for understanding the model and resulting requirements.
NEA工作组的优先任务是在参考模型的更高层制定标准协议（见第5节）：姿势属性协议（PA）和姿势代理协议（PB）。PA和PB将设计为通过各种低层传输（PT）协议传输。NEA工作组将确定强制实施的标准PT协议。PT协议可在其他工作组中定义，因为要求可能不是NEA特有的。当与标准PT协议（例如，可扩展认证协议（EAP）、传输层安全协议（TLS）[TLS]）一起使用时，PA和PB协议将允许一家供应商的NEA客户端与另一家供应商的NEA服务器之间的互操作性。本规范不关注NEA参考模型功能组件之间的其他接口，也不关注其内部要求。对这些方面的任何讨论都是为了提供理解模型和最终需求的上下文。
Some tangent areas not shown in the reference model that are also out of scope for the NEA working group, and thus this specification, include:
参考模型中未显示的一些切线区域也超出了NEA工作组的范围，因此本规范包括：
o Standardizing the protocols and mechanisms for enforcing restricted network access,
o 标准化用于实施受限网络访问的协议和机制，
o Developing standard protocols for remediation of non-compliant endpoints,
o 制定补救不合规端点的标准协议，
o Specifying protocols used to communicate with remote portions of the NEA Client or Server (e.g., remote collectors or validators of posture),
o 指定用于与NEA客户端或服务器远程部分通信的协议（例如，姿态的远程采集器或验证器），
o Supporting a NEA Client providing posture for other endpoints (e.g., a NEA Client on an Intrusion Detection System (IDS) providing posture for an endpoint without a NEA Client),
o 支持为其他端点提供姿势的NEA客户端（例如，入侵检测系统（IDS）上的NEA客户端为没有NEA客户端的端点提供姿势），
o Defining the set of events or situations that might trigger a NEA Client or NEA Server to request an assessment,
o 定义可能触发NEA客户端或NEA服务器请求评估的一组事件或情况，
o Detecting or handling lying endpoints (see section 8.1.1 for more information).
o 检测或处理躺着的端点（有关更多信息，请参阅第8.1.1节）。
Because the NEA model is based on NEA-oriented software being present on the endpoint and in the network infrastructure, and due to the nature of the information being exposed, the use of NEA technologies may not apply in a variety of situations possible on the Internet. Therefore, this section discusses some of the scenarios where NEA is most likely to be applicable and some where it may not be. Ultimately, the use of NEA within a deployment is not restricted to just these scenarios. The decision of whether to use NEA technologies lies in the hands of the deployer (e.g., network provider) based upon the expected relationship they have with the owners and users of potential endpoints.
由于NEA模型基于端点和网络基础设施中存在的面向NEA的软件，并且由于信息的公开性质，NEA技术的使用可能不适用于互联网上可能出现的各种情况。因此，本节讨论了NEA最可能适用的一些场景，以及NEA可能不适用的一些场景。最终，在部署中使用NEA不仅仅限于这些场景。是否使用NEA技术取决于部署者（例如，网络提供商）根据其与潜在端点所有者和用户的预期关系来决定。
NEA technologies are largely focused on scenarios where the owner of the endpoint is the same as the owner of the network. This is a very common model for enterprises that provide equipment to employees to perform their duties. These employees are likely bound under an employment contract that outlines what level of visibility the employer expects to have into the employee's use of company assets and possibly activities during work hours. This contract may establish the expectation that the endpoint needs to conform to policies set forth by the enterprise.
NEA技术主要关注端点所有者与网络所有者相同的场景。对于为员工提供设备以履行其职责的企业来说，这是一种非常常见的模式。这些员工可能受到雇佣合同的约束，该合同概述了雇主希望员工在工作时间内使用公司资产和可能的活动的可见性水平。该合同可以建立端点需要符合企业制定的策略的期望。
Some other environments may be in a similar situation and thus find NEA technologies to be beneficial. For example, environments where the endpoint is owned by a party (possibly even the user) that has explicitly expressed a desire to conform to the policies established by a network or service provider in exchange for being able to access its resources. An example of this might be an independent contractor with a personal laptop, working for a company imposing NEA assessment policies on its employees, who may wish a similar level of access and is willing to conform to the company's policies. NEA technologies may be applicable to this situation.
其他一些环境可能处于类似的情况，因此发现NEA技术是有益的。例如，端点由明确表示希望遵守网络或服务提供商建立的策略以换取能够访问其资源的一方（甚至可能是用户）拥有的环境。这方面的一个例子可能是一个拥有个人笔记本电脑的独立承包商，为一家对其员工实施NEA评估政策的公司工作，这些员工可能希望获得类似的访问级别，并愿意遵守公司的政策。NEA技术可能适用于这种情况。
Conversely, some environments where NEA is not expected to be applicable would be environments where the endpoint is owned by a user that has not agreed to conform to a network provider's policies. An example might include when the above contractor visits any public area like the local coffee shop that offers Internet access. This coffee shop would not be expected to be able to use NEA technologies to assess the posture of the contractor's laptop. Because of the potentially invasive nature of NEA technology, such an assessment could amount to an invasion of privacy of the contractor.
相反，NEA预计不适用的某些环境可能是端点归未同意遵守网络提供商政策的用户所有的环境。例如，当上述承包商访问任何公共区域（如提供互联网接入的当地咖啡馆）时。该咖啡店预计无法使用NEA技术评估承包商笔记本电脑的姿态。由于NEA技术的潜在侵入性，此类评估可能构成对承包商隐私的侵犯。
It is more difficult to determine whether NEA is applicable in other environments, so the NEA WG will consider them to be out of scope for consideration and specification. In order for an environment to be considered applicable for NEA, the owner or user of an endpoint must have established a clear expectation that it will comply with the policies of the owner and operator of the network. Such an expectation likely includes a willingness to disclose appropriate information necessary for the network to perform compliance checks.
更难确定NEA是否适用于其他环境，因此NEA WG将认为它们超出了考虑和规范的范围。为了将环境视为适用于NEA，端点的所有者或用户必须建立明确的期望，即其将遵守网络所有者和运营商的政策。这种期望可能包括愿意披露网络执行合规性检查所需的适当信息。
NEA technology may be used for a variety of purposes. This section highlights some of the major situations where NEA technologies may be beneficial.
NEA技术可用于多种用途。本节重点介绍了NEA技术可能有益的一些主要情况。
One use is to facilitate endpoint compliance checking against an organization's security policy when an endpoint connects to the network. Organizations often require endpoints to run an IT-specified Operating System (OS) configuration and have certain security applications enabled, e.g., anti-virus software, host intrusion detection/prevention systems, personal firewalls, and patch management software. An endpoint that is not compliant with IT policy may be vulnerable to a number of known threats that might exist on the network.
一种用途是在端点连接到网络时，根据组织的安全策略促进端点符合性检查。组织通常要求端点运行IT指定的操作系统（OS）配置，并启用某些安全应用程序，例如，防病毒软件、主机入侵检测/预防系统、个人防火墙和修补程序管理软件。不符合IT策略的端点可能容易受到网络上可能存在的许多已知威胁的攻击。
Without NEA technology, ensuring compliance of endpoints to corporate policy is a time-consuming and difficult task. Not all endpoints are managed by a corporation's IT organization, e.g., lab assets and contractor machines. Even for assets that are managed, they may not receive updates in a timely fashion because they are not permanently attached to the corporate network, e.g., laptops. With NEA technology, the network is able to assess an endpoint as soon as it requests access to the network or at any time after joining the network. This provides the corporation an opportunity to check compliance of all NEA-capable endpoints in a timely fashion and facilitate endpoint remediation potentially while quarantined when needed.
如果没有NEA技术，确保端点符合公司政策是一项耗时且困难的任务。并非所有端点都由公司的IT组织管理，例如实验室资产和承包商机器。即使是管理的资产，它们也可能无法及时接收更新，因为它们没有永久连接到公司网络，例如笔记本电脑。使用NEA技术，网络能够在请求访问网络时或加入网络后的任何时间评估端点。这为公司提供了及时检查所有支持NEA的端点的合规性的机会，并在必要时隔离时促进端点补救。
NEA technology can be used to provide posture assessment for a range of ways of connecting to the network including (but not limited to) wired and wireless LAN access such as using 802.1X [802.1X], remote access via IPsec [IPSEC], or Secure Socket Layer (SSL) VPN, or gateway access.
NEA技术可用于为一系列连接到网络的方式提供姿态评估，包括（但不限于）有线和无线LAN访问，例如使用802.1X[802.1X]、通过IPsec[IPsec]远程访问或安全套接字层（SSL）VPN或网关访问。
Endpoints that are not NEA-capable or choose not to share sufficient posture to evaluate compliance may be subject to different access policies. The decision of how to handle non-compliant or non-participating endpoints can be made by the network administrator possibly based on information from other security mechanisms on the network (e.g., authentication). For example, remediation instructions or warnings may be sent to a non-compliant endpoint with a properly authorized user while allowing limited access to the network. Also, network access technologies can use the NEA results to restrict or deny access to an endpoint, while allowing vulnerabilities to be addressed before an endpoint is exposed to attack. The communication and representation of NEA assessment results to network access technologies on the network is out of scope for this document.
不支持NEA或选择不共享足够姿态以评估合规性的端点可能会受到不同访问策略的约束。网络管理员可以根据来自网络上其他安全机制的信息（例如，身份验证），决定如何处理不兼容或不参与的端点。例如，在允许对网络进行有限访问的同时，可以向具有适当授权的用户的不合规端点发送修正指令或警告。此外，网络访问技术可以使用NEA结果来限制或拒绝对端点的访问，同时允许在端点暴露于攻击之前解决漏洞。NEA评估结果在网络上与网络接入技术的通信和表示超出了本文件的范围。
Reassessment is a second important use of NEA technology as it allows for additional assessments of previously considered compliant endpoints to be performed. This might become necessary because network compliance policies and/or endpoint posture can change over time. A system initially assessed as being compliant when it joined the network may no longer be in compliance after changes occur. For example, reassessment might be necessary if a user disables a security protection (e.g., host-based firewall) required by policy or when the firewall becomes non-compliant after a firewall patch is issued and network policy is changed to require the patch.
重新评估是NEA技术的第二个重要用途，因为它允许对先前考虑的符合性终点进行额外评估。这可能是必要的，因为网络合规性策略和/或端点姿态可能会随时间而变化。当系统加入网络时，最初评估为符合要求的系统在发生更改后可能不再符合要求。例如，如果用户禁用策略所需的安全保护（例如，基于主机的防火墙），或者在发布防火墙修补程序且网络策略更改为需要该修补程序后，防火墙变得不兼容，则可能需要重新评估。
A third use of NEA technology may be to verify or supplement organization asset information stored in inventory databases.
NEA技术的第三个用途可能是验证或补充库存数据库中存储的组织资产信息。
NEA technology can also be used to check and report compliance for endpoints when they try to access certain mission critical applications within an enterprise, employing service (application) triggered assessment.
当端点尝试访问企业内的某些关键应用程序时，NEA技术还可用于检查和报告端点的合规性，采用服务（应用程序）触发的评估。
This section describes the reference model for Network Endpoint Assessment. This model is provided to establish a context for the discussion of requirements and may not directly map to any particular product or deployment architecture. The model identifies the major
本节介绍网络端点评估的参考模型。提供此模型是为了建立需求讨论的上下文，可能不会直接映射到任何特定的产品或部署体系结构。该模型确定了主要的
functionality of the NEA Client and Server and their relationships, as well as the protocols they use to communicate at various levels (e.g., PA is carried by the PB protocol).
NEA客户端和服务器的功能及其关系，以及用于在不同级别进行通信的协议（例如，PA由PB协议承载）。
While the diagram shows 3 layered protocols, it is envisioned that PA is likely a thin message wrapper around a set of attributes and that it is batched and encapsulated in PB. PB is primarily a lightweight message batching protocol, so the protocol stack is mostly the transport (PT). The vertical lines in the model represent APIs and/or protocols between components within the NEA Client or Server. These interfaces are out of scope for standardization in the NEA WG.
虽然图中显示了3个分层协议，但可以预见PA很可能是一个围绕一组属性的瘦消息包装器，并且它被批处理并封装在PB中。PB主要是一种轻量级消息批处理协议，因此协议栈主要是传输协议（PT）。模型中的垂直线表示NEA客户端或服务器内组件之间的API和/或协议。这些接口超出了NEA工作组的标准化范围。
+-------------+ +--------------+
| Posture | <--------PA--------> | Posture |
| Collectors | | Validators |
| (1 .. N) | | (1 .. N) |
+-------------+ +--------------+
| |
| |
| |
+-------------+ +--------------+
| Posture | | Posture |
| Broker | <--------PB--------> | Broker |
| Client | | Server |
+-------------+ +--------------+
| |
| |
+-------------+ +--------------+
| Posture | | Posture |
| Transport | <--------PT--------> | Transport |
| Client | | Server |
| (1 .. N) | | (1 .. N) |
+-------------+ +--------------+
+-------------+ +--------------+
| Posture | <--------PA--------> | Posture |
| Collectors | | Validators |
| (1 .. N) | | (1 .. N) |
+-------------+ +--------------+
| |
| |
| |
+-------------+ +--------------+
| Posture | | Posture |
| Broker | <--------PB--------> | Broker |
| Client | | Server |
+-------------+ +--------------+
| |
| |
+-------------+ +--------------+
| Posture | | Posture |
| Transport | <--------PT--------> | Transport |
| Client | | Server |
| (1 .. N) | | (1 .. N) |
+-------------+ +--------------+
NEA CLIENT NEA SERVER
NEA客户端NEA服务器
Figure 1: NEA Reference Model
图1:NEA参考模型
The NEA reference model does not include mechanisms for discovery of NEA Clients and NEA Servers. It is expected that NEA Clients and NEA Servers are configured with information that allows them to reach each other. The specific methods of referencing the configuration and establishing the communication channel are out of scope for the NEA reference model and should be covered in the specifications of candidate protocols such as the Posture Transport (PT) protocol.
NEA参考模型不包括发现NEA客户端和NEA服务器的机制。预计NEA客户端和NEA服务器都配置了允许它们相互联系的信息。参考配置和建立通信信道的具体方法超出了NEA参考模型的范围，应包含在候选协议（如姿态传输（PT）协议）的规范中。
The NEA Client is resident on an endpoint device and comprised of the following functionality:
NEA客户端驻留在终端设备上，由以下功能组成：
o Posture Collector(s)
o 姿势收集器（s）
o Posture Broker Client
o 姿态经纪客户
o Posture Transport Client(s)
o 姿态传输客户端
The NEA Client is responsible for responding to requests for attributes describing the configuration of the local operating domain of the client and handling the assessment results including potential remediation instructions for how to conform to policy. A NEA Client is not responsible for reporting on the posture of entities that might exist on the endpoint or over the network that are outside the domain of execution (e.g., in other virtual machine domains) of the NEA Client.
NEA客户负责响应描述客户本地操作域配置的属性请求，并处理评估结果，包括如何遵守政策的潜在补救说明。NEA客户端不负责报告可能存在于端点上或网络上的实体的姿态，这些实体位于NEA客户端的执行域之外（例如，在其他虚拟机域中）。
For example, a network address translation (NAT) device might route communications for many systems behind it, but when the NAT device joins the network, its NEA Client would only report its own (local) posture. Similarly, endpoints with virtualization capabilities might have multiple independent domains of execution (e.g., OS instances). Each NEA Client is only responsible for reporting posture for its domain of execution, but this information might be aggregated by other local mechanisms to represent the posture for multiple domains on the endpoint. Such posture aggregation mechanisms are outside the focus of this specification.
例如，网络地址转换（NAT）设备可能会为其背后的许多系统路由通信，但当NAT设备加入网络时，其NEA客户端只会报告其自身（本地）姿态。类似地，具有虚拟化功能的端点可能具有多个独立的执行域（例如，操作系统实例）。每个NEA客户端只负责报告其执行域的状态，但该信息可能由其他本地机制聚合，以表示端点上多个域的状态。这种姿态聚合机制不属于本规范的重点。
Endpoints lacking NEA Client software (which is out of NEA scope) or choosing not to provide the attributes required by the NEA Server could be considered non-compliant. The NEA model includes capabilities to enable the endpoint to update its contents in order to become compliant.
缺少NEA客户端软件（不在NEA范围内）或选择不提供NEA服务器所需属性的端点可能被视为不符合要求。NEA模型包括使端点能够更新其内容以符合要求的功能。
The Posture Collector is responsible for responding to requests for posture information in Request Attributes from the NEA Server. The Posture Collector is also responsible for handling assessment decisions in Result Attributes and remediation instructions in Remediation Attributes. A single NEA Client can have several Posture Collectors capable of collecting standard and/or vendor-specific Posture Attributes for particular features of the endpoint. Typical
姿态采集器负责响应来自NEA服务器的请求属性中的姿态信息请求。姿态收集器还负责处理结果属性中的评估决策和修正属性中的修正指令。单个NEA客户端可以有多个姿态采集器，能够收集端点特定特征的标准和/或供应商特定姿态属性。典型的
examples include Posture Collectors that provide information about Operating System (OS) version and patch levels, anti-virus software, and security mechanisms on the endpoint such as host-based Intrusion Detection System (IDS) or firewall.
示例包括姿态收集器，提供有关操作系统（OS）版本和修补程序级别、防病毒软件以及端点上的安全机制（如基于主机的入侵检测系统（IDS）或防火墙）的信息。
Each Posture Collector will be associated with one or more identifiers that enable it to be specified as the destination in a PA message. The Posture Broker Client uses these identifiers to route messages to this Collector. An identifier might be dynamic (e.g., generated by the Posture Broker Client at run-time during registration) or more static (e.g., pre-assigned to the Posture Collector at install-time and passed to the Posture Broker Client during registration) or a function of the attribute messages the Collector desires to receive (e.g., message type for subscription).
每个姿势收集器将与一个或多个标识符相关联，这些标识符使其能够在PA消息中被指定为目的地。姿态代理客户端使用这些标识符将消息路由到此收集器。标识符可能是动态的（例如，在注册期间由姿态代理客户端在运行时生成）或更静态的（例如，在安装时预先分配给姿态收集器，并在注册期间传递给姿态代理客户端）或收集器希望接收的属性消息的函数（例如，订阅的消息类型）。
The NEA model allocates the following responsibilities to the Posture Collector:
NEA模型将以下职责分配给姿势收集器：
o Consulting with local privacy and security policies that may restrict what information is allowed to be disclosed to a given NEA Server.
o 咨询当地隐私和安全政策，这些政策可能会限制允许向给定NEA服务器披露的信息。
o Receiving Request Attributes from a Posture Validator and performing the local processing required to respond appropriately. This may include:
o 从姿势验证器接收请求属性，并执行适当响应所需的本地处理。这可能包括：
- Collecting associated posture information for particular features of the endpoint and returning this information in Posture Attributes.
- 收集端点特定特征的关联姿势信息，并在姿势属性中返回此信息。
- Caching and recognizing the applicability of recently issued attributes containing reusable assertions that might serve to prove compliance and returning this attribute instead of posture information.
- 缓存并识别最近发布的属性的适用性，这些属性包含可用于证明符合性的可重用断言，并返回此属性而不是姿势信息。
o Receiving attributes containing remediation instructions on how to update functionality on the endpoint. This could require the Collector to interact with the user, owner, and/or a remediation server.
o 接收属性，其中包含有关如何更新端点功能的修正说明。这可能需要收集器与用户、所有者和/或修正服务器交互。
o Monitoring the posture of (a) particular features(s) on the endpoint for posture changes that require notification to the Posture Broker Client.
o 监控端点上特定特征的姿态，以了解需要通知姿态代理客户端的姿态更改。
o Providing cryptographic verification of the attributes received from the Validator and offering cryptographic protection to the attributes returned.
o 为从验证器接收的属性提供加密验证，并为返回的属性提供加密保护。
The above list describes the model's view of the possible responsibilities of the Posture Collector. Note that this is not a set of requirements for what each Posture Collector implementation must support, nor is it an exhaustive list of all the things a Posture Collector may do.
上面的列表描述了模型对姿势收集器可能职责的视图。请注意，这不是每个姿态收集器实现必须支持的一组要求，也不是姿态收集器可能执行的所有操作的详尽列表。
The Posture Broker Client is both a PA message multiplexer and a de-multiplexer. The Posture Broker Client is responsible for de-multiplexing the PB message received from the NEA Server and distributing each encapsulated PA message to the corresponding Posture Collector(s). The model also allows for the posture information request to be pre-provisioned on the NEA Client to improve performance by allowing the NEA Client to report posture without receiving a request for particular attributes from the NEA Server.
姿态代理客户端既是PA消息多路复用器又是解多路复用器。姿态代理客户端负责解复用从NEA服务器接收的PB消息，并将每个封装的PA消息分发到相应的姿态收集器。该模型还允许在NEA客户端上预先设置姿势信息请求，以通过允许NEA客户端报告姿势而不接收来自NEA服务器的特定属性请求来提高性能。
The Posture Broker Client also multiplexes the responses from the Posture Collector(s) and returns them to the NEA Server. The Posture Broker Client constructs one or more PB messages using the PA message(s) it obtains from the Posture Collector(s) involved in the assessment. The quantity and ordering of Posture Collector responses (PA message(s)) multiplexed into the PB response message(s) can be determined by the Posture Broker Client based on many factors including policy or characteristics of the underlying network transport (e.g., MTU). A particular NEA Client will have one Posture Broker Client.
姿态代理客户端还多路传输来自姿态采集器的响应，并将其返回给NEA服务器。姿态代理客户端使用从评估中涉及的姿态收集器获得的PA消息构造一个或多个PB消息。复用到PB响应消息中的姿态收集器响应（PA消息）的数量和顺序可由姿态代理客户端基于许多因素确定，这些因素包括底层网络传输（例如，MTU）的策略或特征。特定的NEA客户将有一个姿态代理客户。
The Posture Broker Client also handles the global assessment decision from the Posture Broker Server and may interact with the user to communicate the global assessment decision and aid in any necessary remediation steps.
姿态代理客户端还处理来自姿态代理服务器的全局评估决策，并可与用户交互以传达全局评估决策，并在任何必要的补救步骤中提供帮助。
The NEA model allocates the following responsibilities to the Posture Broker Client:
NEA模型将以下职责分配给姿态经纪客户：
o Maintaining a registry of known Posture Collectors and allowing for Posture Collectors to dynamically register and deregister.
o 维护已知姿势收集器的注册表，并允许姿势收集器动态注册和注销。
o Multiplexing and de-multiplexing attribute messages between the NEA Server and the relevant Posture Collectors.
o 在NEA服务器和相关姿态采集器之间复用和解复用属性消息。
o Handling posture change notifications from Posture Collectors and triggering reassessment.
o 处理来自姿势收集器的姿势更改通知并触发重新评估。
o Providing user notification about the global assessment decision and other user messages sent by the NEA Server.
o 提供关于全局评估决策的用户通知以及NEA服务器发送的其他用户消息。
The Posture Transport Client is responsible for establishing a reliable communication channel with the NEA Server for the message dialog between the NEA Client and NEA Server. There might be more than one Posture Transport Client on a particular NEA Client supporting different transport protocols (e.g., 802.1X, VPN). Certain Posture Transport Clients may be configured with the address of the appropriate Posture Transport Server to use for a particular network.
姿态传输客户端负责为NEA客户端和NEA服务器之间的消息对话与NEA服务器建立可靠的通信通道。特定NEA客户端上可能有多个姿态传输客户端支持不同的传输协议（例如802.1X、VPN）。某些姿态传输客户端可配置有用于特定网络的适当姿态传输服务器的地址。
The NEA model allocates the following responsibilities to the Posture Transport Client:
NEA模型将以下职责分配给运输客户：
o Initiating and maintaining the communication channel to the NEA Server. The Posture Transport Client hides the details of the underlying carrier that could be a Layer 2 or Layer 3 protocol.
o 启动并维护与NEA服务器的通信信道。姿态传输客户端隐藏底层载波的详细信息，该载波可能是第2层或第3层协议。
o Providing cryptographic protection for the message dialog between the NEA Client and NEA Server.
o 为NEA客户端和NEA服务器之间的消息对话框提供加密保护。
The NEA Server is typically comprised of the following NEA functionality:
NEA服务器通常由以下NEA功能组成：
o Posture Validator(s)
o 姿势验证器
o Posture Broker Server
o 姿态代理服务器
o Posture Transport Server(s)
o 姿态传输服务器
The Posture Validators might be located on a separate server from the Posture Broker Server, requiring the Posture Broker Server to deal with both local and remote Posture Validators.
姿态验证器可能位于与姿态代理服务器不同的服务器上，需要姿态代理服务器处理本地和远程姿态验证器。
A Posture Validator is responsible for handling Posture Attributes from corresponding Posture Collector(s). A Posture Validator can handle Posture Attributes from one or more Posture Collectors and vice-versa. The Posture Validator performs the posture assessment for one or more features of the endpoint (e.g., anti-virus software) and creates the result and, if necessary, the remediation instructions, or it may choose to request additional attributes from one or more Collectors.
姿势验证器负责处理来自相应姿势收集器的姿势属性。姿势验证器可以处理来自一个或多个姿势收集器的姿势属性，反之亦然。姿态验证器对端点的一个或多个功能（例如，防病毒软件）执行姿态评估，并创建结果，如有必要，创建修正说明，或者选择从一个或多个收集器请求附加属性。
Each Posture Validator will be associated with one or more identifiers that enable it to be specified as the destination in a PA message. The Posture Broker Server uses this identifier to route messages to this Validator. This identifier might be dynamic (e.g., generated by the Posture Broker Server at run-time during registration) or more static (e.g., pre-assigned to a Posture Validator at install-time and passed to the Posture Broker Server during registration) or a function of the attribute messages the Validator desires to receive (e.g., message type for subscription).
每个姿势验证器将与一个或多个标识符相关联，使其能够在PA消息中被指定为目的地。姿态代理服务器使用此标识符将消息路由到此验证器。该标识符可能是动态的（例如，注册期间由姿态代理服务器在运行时生成），也可能是更静态的（例如，在安装时预先分配给姿态验证器，并在注册期间传递给姿态代理服务器），或者是验证器希望接收的属性消息的函数（例如，订阅的消息类型）。
Posture Validators can be co-located on the NEA Server or can be hosted on separate servers. A particular NEA Server is likely to need to handle multiple Posture Validators.
姿态验证器可以位于NEA服务器上，也可以托管在单独的服务器上。特定的NEA服务器可能需要处理多个姿态验证器。
The NEA model allocates the following responsibilities to the Posture Validator:
NEA模型将以下职责分配给姿势验证器：
o Requesting attributes from a Posture Collector. The request may include:
o 从姿态收集器请求属性。请求可包括：
- Request Attributes that indicate to the Posture Collector to fetch and provide Posture Attributes for particular functionality on the endpoint.
- 请求属性，这些属性指示姿态采集器获取并提供端点上特定功能的姿态属性。
o Receiving attributes from the Posture Collector. The response from the Posture Collector may include:
o 从姿态收集器接收属性。来自姿势收集器的响应可以包括：
- Posture Attributes collected for the requested functionality.
- 为请求的功能收集的姿势属性。
- Assertion Attributes that indicate the compliance result from a prior assessment.
- 断言属性，指示先前评估的符合性结果。
o Assessing the posture of endpoint features based on the attributes received from the Collector.
o 基于从收集器接收的属性评估端点特征的姿态。
o Communicating the posture assessment result to the Posture Broker Server.
o 将姿势评估结果传送给姿势代理服务器。
o Communicating the posture assessment results to the Posture Collector; this attribute message may include:
o 将姿势评估结果传达给姿势收集器；此属性消息可能包括：
- Result Attributes that communicate the posture assessment result. - Remediation Attributes that communicate the remediation instructions to the Posture Collector.
- 传达姿势评估结果的结果属性。-将修正指令传达给姿态采集器的修正属性。
o Monitoring out-of-band updates that trigger reassessment and require notifications to be sent to the Posture Broker Server.
o 监视带外更新，这些更新会触发重新评估并要求将通知发送到姿态代理服务器。
o Providing cryptographic protection for attributes sent to the Posture Collector and offering cryptographic verification of the attributes received from the Posture Collector.
o 为发送到姿态采集器的属性提供加密保护，并对从姿态采集器接收的属性提供加密验证。
The above list describes the model's view of the possible responsibilities of the Posture Validator. Note that this is not a set of requirements for what each Posture Validator implementation must support, nor is it an exhaustive list of all the things a Posture Validator may do.
上面的列表描述了模型对姿势验证器可能职责的看法。请注意，这并不是每个姿势验证器实现必须支持的一组需求，也不是姿势验证器可以做的所有事情的详尽列表。
The Posture Broker Server acts as a multiplexer and a de-multiplexer for attribute messages. The Posture Broker Server parses the PB messages received from the NEA Client and de-multiplexes them into PA messages that it passes to the associated Posture Validators. The Posture Broker Server multiplexes the PA messages (e.g., messages containing (a) Request Attribute(s) from the relevant Posture Validator(s)) into one or more PB messages and sends them to the NEA Client via the Posture Transport protocol. The quantity and ordering of Posture Validator responses (PA messages) and global assessment decision multiplexed into the PB response message(s) can be determined by the Posture Broker Server based on many factors including policy or characteristics of the underlying network transport (e.g., MTU).
姿态代理服务器充当属性消息的多路复用器和解多路复用器。姿态代理服务器解析从NEA客户端接收的PB消息，并将其解复用为PA消息，然后传递给相关的姿态验证器。姿态代理服务器将PA消息（例如，包含来自相关姿态验证器的（a）请求属性的消息）复用到一个或多个PB消息中，并通过姿态传输协议将其发送到NEA客户端。姿态验证器响应（PA消息）和复用到PB响应消息中的全局评估决策的数量和顺序可由姿态代理服务器基于许多因素确定，这些因素包括底层网络传输（例如MTU）的策略或特征。
The Posture Broker Server is also responsible for computing the global assessment decision based on individual posture assessment results from the various Posture Validators. This global assessment decision is sent back to the NEA Client in Result Attributes within a PB message. A particular NEA Server will have one Posture Broker Server, and this Posture Broker Server will handle all the local and remote Posture Validators.
姿态代理服务器还负责根据来自各种姿态验证器的各个姿态评估结果计算全局评估决策。该全局评估决定将在PB消息的结果属性中发送回NEA客户端。特定的NEA服务器将有一个姿态代理服务器，该姿态代理服务器将处理所有本地和远程姿态验证器。
The NEA model allocates the following responsibilities to the Posture Broker Server:
NEA模型将以下职责分配给姿态代理服务器：
o Maintaining a registry of Posture Validators and allowing for Posture Validators to register and deregister.
o 维护姿势验证器的注册，并允许姿势验证器注册和注销。
o Multiplexing and de-multiplexing posture messages from and to the relevant Posture Validators.
o 从相关姿势验证器多路复用和解多路复用姿势消息。
o Computing the global assessment decision based on posture assessment results from the various Posture Validators and compliance policy. This assessment decision is sent to the Posture Broker Client in a PB message.
o 根据来自各种姿势验证器和合规性策略的姿势评估结果计算全局评估决策。此评估决定将在PB消息中发送给姿态代理客户端。
The Posture Transport Server is responsible for establishing a reliable communication channel with the NEA Client for the message dialog between the NEA Client and NEA Server. There might be more than one Posture Transport Server on a particular NEA Server to support different transport protocols. A particular Posture Transport Server will typically handle requests from several Posture Transport Clients and may require local configuration describing how to reach the NEA Clients.
姿态传输服务器负责为NEA客户端和NEA服务器之间的消息对话与NEA客户端建立可靠的通信通道。特定NEA服务器上可能有多个姿态传输服务器，以支持不同的传输协议。特定的姿态传输服务器通常将处理来自多个姿态传输客户端的请求，并且可能需要描述如何到达NEA客户端的本地配置。
The NEA model allocates the following responsibilities to the Posture Transport Server:
NEA模型将以下职责分配给姿态传输服务器：
o Initiating and maintaining a communication channel with, potentially, several NEA Clients.
o 启动并维护可能与多个NEA客户端的通信通道。
o Providing cryptographic protection for the message dialog between the NEA Client and NEA Server.
o 为NEA客户端和NEA服务器之间的消息对话框提供加密保护。
The NEA reference model includes three layered protocols (PA, PB, and PT) that allow for the exchange of attributes across the network. While these protocols are intended to be used together to fulfill a particular role in the model, they may offer overlapping functionality. For example, each protocol should be capable of protecting its information from attack (see section 8.2 for more information).
NEA参考模型包括三个分层协议（PA、PB和PT），允许跨网络交换属性。虽然这些协议旨在一起使用以实现模型中的特定角色，但它们可能提供重叠的功能。例如，每个协议都应该能够保护其信息免受攻击（有关更多信息，请参阅第8.2节）。
PA is a protocol that carries one or more attributes between Posture Collectors and their associated Posture Validator. The PA protocol is a message-oriented lightweight wrapper around a set of attributes being exchanged. This wrapper may indicate the purpose of attributes within the message. Some of the types of messages expected include: requests for posture information (Request Attributes), posture information about the endpoint (Posture Attributes), results of an assessment (Result Attributes), reusable compliance assertions (Assertion Attributes), and instructions to remediate non-compliant portions of the endpoint (Remediation Attributes). The PA protocol also provides the requisite encoding and cryptographic protection for the Posture Attributes.
PA是一种协议，在姿态采集器及其关联的姿态验证器之间承载一个或多个属性。PA协议是围绕正在交换的一组属性的面向消息的轻量级包装器。此包装器可以指示消息中属性的用途。预期的一些消息类型包括：姿势信息请求（请求属性）、关于端点的姿势信息（姿势属性）、评估结果（结果属性）、可重用的符合性断言（断言属性）以及纠正端点不符合部分的说明（修正属性）。PA协议还为姿态属性提供必要的编码和加密保护。
PB is a protocol that carries aggregate attribute messages between the Posture Collectors on the NEA Client and the corresponding Posture Validators on the NEA Server involved in a particular assessment. The PB protocol provides a session allowing for message dialogs for every assessment. This PB session is then used to bind multiple Posture Attribute requests and responses from the different Posture Collectors and Posture Validators involved in a particular assessment. The PB protocol may also carry the global assessment decision in the Result Attribute from the Posture Broker Server to the Posture Broker Client. PB may be used to carry additional types of messages for use by the Posture Broker Client and Server (e.g., information about user preferred interface settings such as language).
PB是一种协议，它在NEA客户端上的姿态采集器和参与特定评估的NEA服务器上的相应姿态验证器之间承载聚合属性消息。PB协议提供了一个会话，允许对每次评估进行消息对话。然后，此PB会话用于绑定来自特定评估中涉及的不同姿势收集器和姿势验证器的多个姿势属性请求和响应。PB协议还可以将结果属性中的全局评估决策从姿态代理服务器传送到姿态代理客户端。PB可用于承载其他类型的消息，供姿态代理客户端和服务器使用（例如，有关用户首选界面设置的信息，如语言）。
PT is a transport protocol between the NEA Client and the NEA Server responsible for carrying the messages generated by the PB protocol. The PT protocol(s) transport(s) PB messages during the network connection request or after network connectivity has been established.
PT是NEA客户端和负责承载PB协议生成的消息的NEA服务器之间的传输协议。PT协议在网络连接请求期间或网络连接建立后传输PB消息。
In scenarios where an initial assessment needs to occur during the network connection, the PT protocol (e.g., EAP within 802.1X) may have constrained use of the network, so deployments may choose to limit the amount and/or size of the attributes exchanged. The NEA Client and NEA Server should be able to detect when a potentially constrained situation exists prior to the assessment based upon properties of the underlying network protocol. Using this information, NEA policy could dictate what aspects of the endpoint to include in the initial assessment and potentially limit the PA message attributes exchanged. This could be followed up by a full reassessment after the endpoint is placed on the network. Alternatively, deployments can choose not to limit their assessment by configuring their network access technology to temporarily grant restricted IP connectivity prior to the assessment and use an unconstrained, high bandwidth IP-based transport during the assessment. Some of the constraints that may exist for protocols involved in the network connection phase include:
在网络连接期间需要进行初始评估的场景中，PT协议（例如802.1X中的EAP）可能限制了网络的使用，因此部署可能会选择限制交换属性的数量和/或大小。NEA客户端和NEA服务器应能够在根据基础网络协议的属性进行评估之前检测到可能存在的受限情况。使用此信息，NEA策略可以规定初始评估中要包括端点的哪些方面，并可能限制交换的PA消息属性。在将端点放置到网络上之后，可以进行全面的重新评估。或者，部署可以选择不限制其评估，方法是将其网络访问技术配置为在评估之前临时授予受限的IP连接，并在评估期间使用无约束、高带宽的基于IP的传输。网络连接阶段涉及的协议可能存在的一些约束包括：
o Limited maximum transmission unit (MTU) size and ability to negotiate larger MTUs,
o 有限的最大传输单元（MTU）尺寸和通过较大MTU的能力，
o Inability to perform multiple roundtrips,
o 无法执行多次往返，
o Lack of support for piggybacking attributes for other protocols,
o 缺少对其他协议的搭载属性的支持，
o Low bandwidth or high latency limitations precluding exchanges of large amounts of data,
o 低带宽或高延迟限制妨碍了大量数据的交换，
o Inability of servers to initiate messages except during the network connection phase.
o 服务器无法启动消息，除非在网络连接阶段。
The PT protocol selection process needs to consider the impact of selecting a particular PT and set of underlying protocols on the deployment needs of PA and PB. PA and PB will be selected prior to PT so the needs of PA and PB will be known. Certain underlying protocol stacks may be too constrained to support adequate NEA assessments during network connection.
PT协议选择过程需要考虑选择一个特定的PT和一组底层协议对PA和PB部署需求的影响。PA和PB将在PT之前选择，以便了解PA和PB的需求。在网络连接期间，某些底层协议栈可能过于受限，无法支持充分的NEA评估。
The PT protocol provides reliable message delivery, mutual authentication, and cryptographic protection for the PB messages as specified by local policy.
PT协议为本地策略指定的PB消息提供可靠的消息传递、相互身份验证和加密保护。
The PA protocol is responsible for the exchange of attributes between a Posture Collector and Posture Validator. The PB protocol may also carry the global assessment decision attributes from the Posture Broker Server. Attributes are effectively the reserved word 'nouns' of the posture assessment. The NEA Server is only able to ask for information that has a corresponding attribute, thus bounding what type of posture can be obtained. The NEA WG will define a common (standard) set of attributes that are expected to be widely applicable to Posture Collectors and thus used for maximum interoperability, but Posture Collectors may support additional vendor-specific attributes when necessary.
PA协议负责姿势收集器和姿势验证器之间的属性交换。PB协议还可以携带来自姿态代理服务器的全局评估决策属性。属性实际上是姿势评估的保留词“名词”。NEA服务器只能请求具有相应属性的信息，从而限定可以获得的姿势类型。NEA工作组将定义一组通用（标准）属性，这些属性预计将广泛适用于姿态采集器，从而实现最大的互操作性，但姿态采集器可在必要时支持其他特定于供应商的属性。
Depending on the deployment scenario, the purpose of the attributes exchanged may be different (e.g., posture information vs. asserted compliance). This section discusses the originator and expected situation resulting in the use of each classification of attributes in a PA message. These classifications are not intended to dictate how the NEA WG will specify the attributes when defining the attribute namespace or schema.
根据部署场景的不同，交换属性的目的可能会有所不同（例如，姿势信息与断言的合规性）。本节讨论了发起人以及导致PA消息中使用每种属性分类的预期情况。这些分类并不是为了说明NEA WG在定义属性名称空间或模式时将如何指定属性。
5.3.1. Attributes Normally Sent by NEA Client:
5.3.1. NEA客户端通常发送的属性：
o Posture Attributes - Attributes and values sent to report information about a particular aspect (based on semantic of the attribute) of the system. These attributes are typically sent in response to Request Attributes from the NEA Server. For example, a set of Posture Attributes might describe the status of the host-based firewall (e.g., if running, vendor, version). The NEA Server would base its decision on comparing this type of attribute against policy.
o 姿态属性-发送用于报告系统特定方面（基于属性语义）信息的属性和值。这些属性通常是响应来自NEA服务器的请求属性而发送的。例如，一组姿态属性可能描述基于主机的防火墙的状态（例如，如果正在运行，供应商，版本）。NEA服务器的决策将基于将此类属性与策略进行比较。
o Assertion Attributes - Attributes stating recent prior compliance to policy in hopes of avoiding the need to recollect the posture and send it to the NEA Server. Examples of assertions include (a) NEA Server provided attributes (state) describing a prior evaluation (e.g., opaque to endpoint, signed, time stamped items stating specific results) or (b) NEA Client identity information used by the NEA Server to locate state about prior decisions (e.g., system-bound cookie). These might be returned in lieu of, or in addition to, Posture Attributes.
o 断言属性-声明最近先前遵守策略的属性，以避免需要重新收集姿势并将其发送到NEA服务器。断言的示例包括（a）NEA服务器提供的描述先前评估的属性（状态）（例如，对端点不透明、签名、带有时间戳的项目表示特定结果）或（b）NEA服务器用于定位先前决策状态的NEA客户端身份信息（例如，系统绑定cookie）。可以返回这些属性来代替或补充姿势属性。
5.3.2. Attributes Normally Sent by NEA Server:
5.3.2. 通常由NEA服务器发送的属性：
o Request Attributes - Attributes that define the specific posture information desired by the NEA Server. These attributes might effectively form a template that the Posture Collector fills in (subject to local policy restrictions) with the specific value corresponding to each attribute. The resulting attributes are typically Posture or Assertion Attributes from the NEA Client.
o 请求属性-定义NEA服务器所需特定姿势信息的属性。这些属性可以有效地形成一个模板，姿态收集器使用每个属性对应的特定值填充该模板（受本地策略限制）。结果属性通常是来自NEA客户端的姿态或断言属性。
o Result Attributes - Attributes that contain the decisions of the Posture Validators and/or Posture Broker Server. The level of detail provided may vary from which individual attributes were compliant or not through just the global assessment decision.
o 结果属性—包含姿势验证器和/或姿势代理服务器的决策的属性。提供的详细程度可能因个别属性是否符合全球评估决定而有所不同。
o Remediation Attributes - Attributes that explain to the NEA Client and its user how to update the endpoint to become compliant with the NEA Server policies. These attributes are sent when the global assessment decision was that the endpoint is not currently compliant. Remediation and Result Attributes may both exist within a NEA Server attribute message.
o 修正属性-向NEA客户端及其用户解释如何更新端点以符合NEA服务器策略的属性。当全局评估决定端点当前不符合时，发送这些属性。修正和结果属性可能都存在于NEA服务器属性消息中。
o Assertion Attributes - Attributes containing NEA Server assertions of compliance to a policy for future use by the NEA Client. See section 5.3.1 for more information.
o 断言属性-包含NEA服务器对策略遵从性的断言的属性，供NEA客户端将来使用。详见第5.3.1节。
This section discusses several of the NEA use cases with intent to describe and collectively bound the NEA problem space under consideration. The use cases provide a context and general rationale for the defined requirements. In order to ease understanding of each use case and how it maps to the reference model, each use case will be accompanied by a simple example and a discussion of how this example relates to the NEA protocols. It should be emphasized that the provided examples are not intended to indicate the only approach to addressing the use case but rather are included to ease understanding of how the flows might occur and impact the NEA protocols.
本节讨论了几个NEA用例，旨在描述并共同界定所考虑的NEA问题空间。用例为定义的需求提供了上下文和一般原理。为了便于理解每个用例及其如何映射到参考模型，每个用例将附带一个简单的示例，并讨论该示例与NEA协议的关系。应该强调的是，所提供的示例并非旨在说明解决用例的唯一方法，而是为了便于理解流可能如何发生并影响NEA协议。
We broadly classify the use cases into two categories, each with its own set of trigger events:
我们将用例大致分为两类，每一类都有自己的触发事件集：
o Initial assessment - evaluation of the posture of an endpoint that has not recently been assessed and thus is not in possession of any valid proof that it should be considered compliant. This evaluation might be triggered by a request to join a network, a request to use a service, or a desire to understand the posture of a system.
o 初始评估-评估最近未评估的终点的姿势，因此没有任何有效证据证明其应被视为符合要求。此评估可能由加入网络的请求、使用服务的请求或了解系统状态的愿望触发。
o Reassessment - evaluation of the posture of an endpoint that has previously been assessed. This evaluation could occur for a variety of reasons including the NEA Client or Server recognizing an occurrence affecting the endpoint that might raise the endpoint's risk level. This could be as simple as it having been a long time since the endpoint's prior reassessment.
o 重新评估-评估先前已评估的终点的姿势。此评估可能出于多种原因进行，包括NEA客户端或服务器发现影响端点的事件可能会提高端点的风险水平。这可能很简单，因为自端点之前的重新评估以来已经有很长一段时间了。
An initial assessment occurs when a NEA Client or Server event occurs that causes the evaluation of the posture of the endpoint for the first time. Endpoints do not qualify for this category of use case if they have been recently assessed and the NEA Client or Server has maintained state (or proof) that the endpoint is compliant and therefore does not need to have its posture evaluated again.
当NEA客户端或服务器事件发生，导致第一次评估端点的姿态时，会发生初始评估。如果最近对端点进行了评估，且NEA客户端或服务器保持端点符合要求的状态（或证据），因此不需要再次评估其姿态，则端点不符合此类用例。
This use case focuses on assessments performed at the time an endpoint attempts to join a network or request use of a service that requires a posture evaluation. This use case is particularly interesting because it allows the NEA Server to evaluate the posture of an endpoint before allowing it access to the network or service.
本用例集中于端点尝试加入网络或请求使用需要姿势评估的服务时执行的评估。这个用例特别有趣，因为它允许NEA服务器在允许其访问网络或服务之前评估端点的姿态。
This approach could be used to help detect endpoints with known vulnerabilities and facilitate their repair before they are admitted to the network and potentially exposed to threats on the network.
此方法可用于帮助检测具有已知漏洞的端点，并在它们进入网络并可能暴露于网络上的威胁之前促进其修复。
A variety of types of endpoint actions could result in this class of assessment. For example, an assessment could be triggered by the endpoint trying to access a highly protected network service (e.g., financial or HR application server) where heightened security checking is required. A better known example could include requesting entrance to a network that requires systems to meet compliance policy. This example is discussed in more detail in the following section.
各种类型的端点动作可能导致此类评估。例如，端点尝试访问需要加强安全检查的高度保护的网络服务（例如，财务或HR应用程序服务器）时，可能会触发评估。一个更广为人知的例子可能包括请求进入要求系统满足法规遵从性策略的网络。下一节将更详细地讨论此示例。
An IT employee returning from vacation boots his office desktop computer that generates a request to join the wired enterprise network. The network's security policy requires the system to provide posture information in order to determine whether the desktop's security features are enabled and up to date. The desktop sends its patch, firewall, and anti-virus posture information. The NEA Server determines that the system is lacking a recent security patch designed to fix a serious vulnerability and the system is placed on a restricted access network. The desktop follows the provided remediation instructions to download and install the necessary patch. Later, the desktop requests again to join the network and this time is provided full access to the enterprise network after a full assessment.
休假归来的IT员工启动办公室台式计算机，生成加入有线企业网络的请求。网络的安全策略要求系统提供姿势信息，以确定桌面的安全功能是否已启用且是最新的。桌面将发送其修补程序、防火墙和防病毒姿态信息。NEA服务器确定系统缺少用于修复严重漏洞的最新安全修补程序，并且系统位于受限访问网络上。桌面按照提供的修复说明下载并安装必要的修补程序。稍后，桌面再次请求加入网络，这一次是在经过全面评估后提供对企业网络的完全访问。
The following describes typical message flows through the NEA reference model for this example use case:
以下描述了本示例用例中通过NEA参考模型的典型消息流：
1. The IT employee's desktop computer connects to the network through an access gateway in the wired enterprise network.
1. IT员工的台式计算机通过有线企业网络中的访问网关连接到网络。
2. The Posture Broker Server on the NEA Server is instructed to assess the endpoint joining the wired network.
2. 指示NEA服务器上的姿态代理服务器评估加入有线网络的端点。
3. Based upon compliance policy, the Posture Broker Server contacts the operating system patch, host-based firewall, and anti-virus Posture Validators to request the necessary posture. Each Posture Validator creates a PA message containing the desired attributes to be requested for assessment from the desktop system.
3. 根据法规遵从性策略，姿态代理服务器联系操作系统修补程序、基于主机的防火墙和防病毒姿态验证器，以请求必要的姿态。每个姿势验证器创建一条PA消息，其中包含从桌面系统请求评估的所需属性。
4. The Posture Broker Server aggregates the PA messages from the Posture Validators into a PB message. The Posture Broker Server passes the PB message to the Posture Transport Server that uses the PT protocol to send the PB message to the NEA Client on the desktop computer.
4. 姿态代理服务器将来自姿态验证器的PA消息聚合为PB消息。姿态代理服务器将PB消息传递给姿态传输服务器，姿态传输服务器使用PT协议将PB消息发送到桌面计算机上的NEA客户端。
5. The Posture Transport Client receives the message from the NEA Server and passes it to the Posture Broker Client for message delivery.
5. 姿态传输客户端从NEA服务器接收消息，并将其传递给姿态代理客户端进行消息传递。
6. The Posture Broker Client de-multiplexes the PB message and delivers the PA messages with the requests for attributes to the firewall, operating system patch, and anti-virus Posture Collectors.
6. 姿态代理客户端对PB消息进行多路复用，并向防火墙、操作系统补丁和防病毒姿态收集器发送PA消息和属性请求。
7. Each Posture Collector involved consults local privacy policy to determine what information is allowed to be disclosed and then returns the requested attributes that are authorized in a PA message to the Posture Broker Client.
7. 每个涉及的姿态收集器都会咨询本地隐私策略，以确定允许披露哪些信息，然后将PA消息中授权的请求属性返回给姿态代理客户端。
8. The Posture Broker Client aggregates these PA messages into a single PB message and sends it to the Posture Broker Server using the Posture Transport Client to Server session.
8. 姿态代理客户端将这些PA消息聚合为单个PB消息，并使用姿态传输客户端到服务器会话将其发送到姿态代理服务器。
9. The Posture Transport Server provides the PB message to the Posture Broker Server that de-multiplexes the message and sends the appropriate attributes to the corresponding Posture Validator.
9. 姿态传输服务器将PB消息提供给姿态代理服务器，该服务器对消息进行多路复用，并将适当的属性发送给相应的姿态验证器。
10. Each Posture Validator compares the values of the attributes it receives with the expected values defined in its policy.
10. 每个姿态验证器将其接收的属性值与其策略中定义的预期值进行比较。
11. The anti-virus and firewall Posture Validators return attributes to the Posture Broker Server stating the desktop computer is compliant, but the operating system patch Posture Validator returns non-compliant. The operating system patch Posture Validator creates a PA message that contains attributes with remediation instructions in addition to the attribute indicating non-compliance result.
11. 防病毒和防火墙姿态验证程序将属性返回给姿态代理服务器，说明桌面计算机符合要求，但操作系统补丁姿态验证程序返回不符合要求的属性。操作系统补丁姿态验证器创建一条PA消息，该消息除了包含指示不合规结果的属性外，还包含带有修正指令的属性。
12. The Posture Broker Server aggregates the PA messages and sends them in a PB message to the Posture Broker Client via the Posture Transport Server and Posture Transport Client.
12. 姿态代理服务器聚合PA消息，并通过姿态传输服务器和姿态传输客户端将它们以PB消息的形式发送到姿态代理客户端。
13. The Posture Broker Client delivers the PA messages with the results from the various Posture Validators to the Posture Collectors including the PA message containing attributes with remediation instructions to the operating system patch Posture Collector. This Posture Collector then interacts with the user to download and install the needed patches, potentially while the endpoint remains quarantined.
13. 姿态代理客户端将PA消息以及来自各种姿态验证器的结果传递给姿态采集器，包括包含属性的PA消息以及操作系统补丁姿态采集器的修正指令。然后，此姿态收集器与用户交互，下载并安装所需的修补程序，而端点可能仍处于隔离状态。
14. Upon completion of the remediation, the above steps 1-10 are repeated (triggered by the NEA Client repeating its request to join the network).
14. 补救完成后，重复上述步骤1-10（由NEA客户端重复其加入网络的请求触发）。
15. This time each involved Posture Validator (including the operating system patch Posture Validator) returns a compliant status and the Posture Broker Server returns a compliant result indicating a global success.
15. 这一次，每个涉及的姿态验证器（包括操作系统补丁姿态验证器）返回一个兼容状态，姿态代理服务器返回一个表示全局成功的兼容结果。
16. The Posture Broker Client receives the compliant result and the IT employee's desktop is now on the network.
16. 姿态代理客户端收到符合要求的结果，IT员工的桌面现在在网络上。
The following are several different aspects of the use case example that potentially need to be factored into the requirements.
下面是用例示例的几个不同方面，这些方面可能需要考虑到需求中。
o Posture assessment before endpoint allowed on network
o 网络允许端点前的姿态评估
o Endpoint sends attributes containing posture information
o 端点发送包含姿势信息的属性
o NEA Server sends remediation instructions
o NEA服务器发送修正指令
o NEA Client causes a reassessment after remediation
o NEA客户在补救后导致重新评估
This use case highlights that an endpoint (possibly at the request of a user) may wish to trigger an assessment of its posture to determine whether its security protective mechanisms are running and up to date.
此用例强调端点（可能应用户请求）可能希望触发对其姿态的评估，以确定其安全保护机制是否正在运行且是最新的。
A student goes to the terminal room to work on a project. The terminal room contains shared systems owned by the school that are on the network. These systems have been previously used by other students so their security posture is unknown. The student wishes to check whether a system is currently in compliance with the school's security policies prior to doing work, so she requests a posture
一个学生去候机室做一个项目。终端机房包含学校拥有的网络共享系统。这些系统以前曾被其他学生使用过，因此他们的安全态势不得而知。学生希望在工作前检查系统当前是否符合学校的安全政策，因此她要求一个姿势
assessment. The NEA Server performs an initial assessment of the system and determines it is compliant but the anti-virus protection is not in use. The student receives an advisory response indicating the system's anti-virus software is turned off but that otherwise it complies with the school's policy. The student turns on the anti-virus software, initiates a scan, and upon completion decides to trust the system with her work.
看法NEA服务器对系统进行初始评估，确定系统符合要求，但未使用防病毒保护。学生收到一份建议回复，表明系统的防病毒软件已关闭，但在其他方面符合学校的政策。学生打开防病毒软件，启动扫描，完成后决定信任系统完成她的工作。
The following describes the message flows through the NEA reference model for the student using a terminal room shared system example:
以下使用航站楼共享系统示例描述了学生NEA参考模型中的信息流：
1. Student triggers the Posture Broker Client on the computer system in the terminal room to initiate a posture assessment.
1. 学生触发终端室计算机系统上的体位代理客户端，以启动体位评估。
2. The Posture Broker Client establishes a session with the Posture Broker Server that causes an assessment to be triggered.
2. 姿态代理客户端与姿态代理服务器建立会话，以触发评估。
3. The Posture Broker Server detects the new session and consults policy to determine that Posture Validators to involve in the assessment. The Posture Broker Server decides to employ several Posture Validators including the anti-virus Posture Validator.
3. 姿态代理服务器检测新会话并咨询策略，以确定姿态验证器将参与评估。姿态代理服务器决定使用多个姿态验证器，包括防病毒姿态验证器。
4. The Posture Validators involved create PA messages containing requests for particular attributes containing information about the desired terminal room computer based on the school's security policy.
4. 所涉及的姿势验证器根据学校的安全策略创建PA消息，其中包含对特定属性的请求，该属性包含有关所需终端机房计算机的信息。
5. The Posture Broker Server assembles a PB message including each of the PA messages from the Posture Validators.
5. 姿态代理服务器组装一个PB消息，其中包括来自姿态验证器的每个PA消息。
6. The Posture Transport Server sends the PB message to the Posture Transport Client where it is passed on to the Posture Broker Client.
6. 姿态传输服务器将PB消息发送到姿态传输客户端，并将其传递到姿态代理客户端。
7. The Posture Broker Client on the student's computer de-multiplexes the PA messages and delivers them to the corresponding Posture Collectors.
7. 学生计算机上的姿态代理客户端对PA消息进行多路复用，并将其发送到相应的姿态采集器。
8. The Posture Collectors consult privacy policy to decide what information to share with the Server. If allowable, the Collectors each return a PA message containing the requested posture to the Posture Broker Client.
8. 收集者可以参考隐私策略来决定与服务器共享哪些信息。如果允许，采集器将向姿态代理客户端返回一条包含请求姿态的PA消息。
9. The Posture Broker Client aggregates the returned PA messages into a PB message and hands it to the Posture Transport Client for transmission to the Posture Transport Server.
9. 姿态代理客户端将返回的PA消息聚合为PB消息，并将其交给姿态传输客户端，以便传输到姿态传输服务器。
10. The Posture Broker Server separates and distributes the Posture Collector PA messages to the associated Posture Validators.
10. 姿态代理服务器将姿态收集器PA消息分离并分发给关联的姿态验证器。
11. The Posture Validators determine whether the attributes containing the posture included in the PA message are compliant with their policies and returns a posture assessment decision to the Posture Broker Server. In this case, the anti-virus Posture Validator returns a PA message indicating a non-compliant result because the anti-virus software is not running and includes attributes describing how to activate the software.
11. 姿势验证器确定包含PA消息中包含的姿势的属性是否符合其策略，并将姿势评估决策返回给姿势代理服务器。在这种情况下，防病毒姿态验证器返回一条PA消息，指示由于防病毒软件未运行而导致的不合规结果，并包含描述如何激活该软件的属性。
12. The Posture Broker Server determines the overall compliance decision based on all of the Validators' assessment results and sends a PB message containing an attribute expressing the global assessment decision and the anti-virus Validator's PA message. In this case, the global assessment decision indicates the system is compliant (despite the anti-virus Validator's result) because the Posture Broker Server policy allowed for the anti-virus to not be running as long as the system was properly patched and running a firewall (which was the case according to the other Posture Validators).
12. 姿态代理服务器根据所有验证器的评估结果确定总体合规性决策，并发送包含表示全局评估决策的属性的PB消息和防病毒验证器的PA消息。在这种情况下，全局评估决定表明系统是兼容的（尽管反病毒验证器的结果如何），因为只要系统正确修补并运行防火墙（根据其他姿态验证器的情况），姿态代理服务器策略允许反病毒不运行。
13. The Posture Transport Server sends the PB message to the Posture Transport Client that provides the message to the Posture Broker Client.
13. 姿态传输服务器向姿态传输客户端发送PB消息，该客户端向姿态代理客户端提供该消息。
14. The Posture Broker Client on the terminal room computer examines the PB message's global assessment decision attribute and reports to the student that the system was deemed to be compliant, but that an advisory was included.
14. 终端机房计算机上的姿态代理客户端检查PB消息的全局评估决策属性，并向学生报告系统被视为符合要求，但包含咨询。
15. The Posture Broker Client provides the PA message with the remediation attributes to the anti-virus Posture Collector that interacts with the user to explain how to turn on anti-virus to improve the local protections.
15. 姿态代理客户端向防病毒姿态收集器提供带有修正属性的PA消息，该收集器与用户交互，以解释如何打开防病毒以改进本地保护。
16. The student turns on the anti-virus software and on completion steps 1-10 are repeated.
16. 学生打开防病毒软件，完成后重复步骤1-10。
17. This time the anti-virus Posture Validator returns a success status and the Posture Broker Server returns a successful global assessment decision in the PB message.
17. 这一次，防病毒姿态验证程序返回成功状态，姿态代理服务器在PB消息中返回成功的全局评估决策。
18. The Posture Broker Client receives the successful global assessment decision in the PB message and the student now uses the computer for her assignment.
18. 姿态代理客户端在PB消息中接收到成功的全局评估决策，学生现在使用计算机完成作业。
The following are several different aspects of the use case example that potentially need to be factored into the requirements.
下面是用例示例的几个不同方面，这些方面可能需要考虑到需求中。
o Voluntary endpoint requested initial assessment,
o 自愿终点要求进行初步评估，
o Successful (compliant) global assessment decision included in PB message with a PA message containing an advisory set of attributes for remediation.
o PB消息中包含成功的（符合要求的）全球评估决策，PA消息包含一组补救建议属性。
Reassessment(s) of endpoints can happen anytime after being admitted to the network after a successful initial NEA assessment. These reassessments may be event-based, such as driven by posture changes detected by the NEA Client, or changes detected by network infrastructure such as detection of suspicious behavior or network policy updates on the NEA Server. They may also be periodic (timer-driven) to reassess the health of the endpoint.
在成功进行初始NEA评估后，可在接入网络后随时重新评估端点。这些重新评估可能是基于事件的，例如由NEA客户端检测到的姿势变化驱动，或者由网络基础设施检测到的变化驱动，例如在NEA服务器上检测到可疑行为或网络策略更新。它们也可以是周期性的（计时器驱动的），以重新评估端点的运行状况。
This use case allows for software on the endpoint or a user to determine that a reassessment of the system is required. There are a variety of reasons why such a reassessment might be beneficial including: changes in its previously reported posture, detection of potentially suspicious behavior, or even to enable the system to periodically poll the NEA Server to assess its condition relative to the latest policies.
此用例允许端点上的软件或用户确定需要重新评估系统。这种重新评估可能有益的原因有很多，包括：改变其先前报告的姿势，检测潜在的可疑行为，甚至使系统能够定期轮询NEA服务器，以评估其相对于最新策略的状况。
The desktops within a company's HR department have a history of poor security practices and eventual compromise. The HR department administrator decides to deploy software on each desktop to monitor the use of security protective mechanisms to assure their use. One day, an HR person accidentally turns off the desktop firewall. The monitoring process detects the lack of a firewall and contacts the NEA Server to request a reassessment of the firewall compliance. The NEA Server returns a decision that the firewall must be reactivated to stay on the network. The NEA Client explains the decision to the user and how to reactivate the firewall. The HR person restarts the firewall and initiates a request to rejoin the network.
公司人力资源部门内的台式机有着不良的安全实践和最终妥协的历史。人力资源部管理员决定在每个桌面上部署软件，以监控安全保护机制的使用，确保其使用。有一天，一名人力资源人员意外关闭了桌面防火墙。监控过程检测到防火墙缺失，并联系NEA服务器请求重新评估防火墙合规性。NEA服务器返回一个决定，即必须重新激活防火墙才能留在网络上。NEA客户端向用户解释该决定以及如何重新激活防火墙。HR人员重新启动防火墙并发起重新加入网络的请求。
The following describes the message flows through the NEA reference model for the HR department example:
以下描述了通过人力资源部示例的NEA参考模型的消息流：
1. The desktop monitoring software that typically might act as a Posture Collector triggers the Posture Broker Client to initiate a posture reassessment. The Posture Broker Client creates a PB message that contains a PA message indicating the desktop firewall has been disabled.
1. 通常可能充当姿势收集器的桌面监控软件会触发姿势代理客户端启动姿势重新评估。姿态代理客户端创建一条PB消息，其中包含指示桌面防火墙已禁用的PA消息。
2. The Posture Broker Client sends the PB message to the Posture Broker Server.
2. 姿态代理客户端向姿态代理服务器发送PB消息。
3. The Posture Transport Client sends the PB message to the Posture Transport Server over the PT protocol.
3. 姿态传输客户端通过PT协议向姿态传输服务器发送PB消息。
4. The Posture Broker Server receives the PB message and forwards the PA message to the firewall Posture Validator for evaluation.
4. 姿态代理服务器接收PB消息并将PA消息转发给防火墙姿态验证器进行评估。
5. The firewall Posture Validator determines that the endpoint is no longer compliant because its firewall has been disabled.
5. 防火墙姿态验证程序确定终结点不再兼容，因为其防火墙已被禁用。
6. The Posture Validator generates a PA message that contains attributes indicating a non-compliant posture assessment result and remediation instructions for how to reactivate the firewall.
6. 姿态验证器生成一条PA消息，该消息包含指示不合规姿态评估结果的属性以及有关如何重新激活防火墙的修正说明。
7. The Posture Validator communicates the PA message with the posture assessment result to the Posture Broker Server to respond back to the NEA Client.
7. 姿势验证器将PA消息与姿势评估结果通信到姿势代理服务器，以响应NEA客户端。
8. The Posture Broker Server generates a PB message including a global assessment decision of non-compliant and the PA message from the firewall Posture Validator.
8. 姿态代理服务器生成一条PB消息，包括不符合的全局评估决定和来自防火墙姿态验证器的PA消息。
9. The Posture Transport Server transports the PB message to the Posture Transport Client where it is passed to the Posture Broker Client.
9. 姿态传输服务器将PB消息传输到姿态传输客户端，并将其传递到姿态代理客户端。
10. The Posture Broker Client processes the attribute containing the global assessment decision received from the NEA Server and displays the non-compliance messages to the user.
10. 姿态代理客户端处理包含从NEA服务器接收的全局评估决策的属性，并向用户显示不合规消息。
11. The Posture Broker Client forwards the PA message to the firewall Posture Collector; the Posture Collector displays the remediation instructions for how to enable the desktop firewall.
11. 姿态代理客户端将PA消息转发给防火墙姿态采集器；姿态收集器显示有关如何启用桌面防火墙的修正说明。
12. The user is prompted to initiate a reassessment after completing the remediation.
12. 完成修正后，系统会提示用户启动重新评估。
13. Upon completion of the remediation, the NEA Client reinitiates a request for reassessment and steps 1-4 are repeated. This time the firewall Posture Validator determines the endpoint is compliant and returns a successful posture assessment decision.
13. 补救完成后，NEA客户重新启动重新评估请求，并重复步骤1-4。这一次，防火墙姿态验证器确定端点是否符合要求，并返回一个成功的姿态评估决策。
14. The Posture Broker Server generates a PB message with a global assessment decision of compliant and returns this to the NEA Client.
14. 姿态代理服务器生成一条PB消息，其中包含符合的全局评估决策，并将其返回给NEA客户端。
The following are several different aspects of the use case example that potentially need to be factored into the requirements.
下面是用例示例的几个不同方面，这些方面可能需要考虑到需求中。
o Voluntary, endpoint (software) initiated posture reassessment request
o 自愿、端点（软件）发起的姿势重新评估请求
o NEA Server requests specific firewall-oriented Posture Attributes
o NEA服务器请求特定的面向防火墙的姿态属性
o NEA Client (firewall Posture Collector) interacts with user to remediate problem
o NEA客户端（防火墙姿态采集器）与用户交互以解决问题
In many cases, especially for reassessment, the NEA Server may initiate specific or complete reassessment of one or more endpoints triggered by:
在许多情况下，尤其是对于重新评估，NEA服务器可能会启动一个或多个端点的特定或完整重新评估，该重新评估由以下原因触发：
o Time (periodic) o Event occurrence o Policy updates
o 时间（周期性）o事件发生o策略更新
An enterprise requires employees on the network to always stay up to date with security critical operating system patches. A marketing employee joins the network and performs an initial assessment. The assessment determines the employee's laptop is compliant. Several
企业要求网络上的员工始终更新安全关键型操作系统补丁。营销人员加入网络并进行初步评估。评估确定员工的笔记本电脑符合要求。几个
hours later, a major operating system vendor releases a set of patches preventing a serious vulnerability that is being exploited on the Internet.
几个小时后，一家主要的操作系统供应商发布了一套补丁，以防止互联网上被利用的严重漏洞。
The enterprise administrators make available the patches and change the network policy to require them to be installed by 5 PM. This policy change causes the NEA Server to request a reassessment to determine which endpoints are impacted and lacking the patches. The marketing employee's laptop is reassessed and determined to need the patches. A remediation advisory is sent and presented to the employee explaining how to obtain the patches and that they must be installed by 5 PM. The marketing employee immediately downloads and installs the patches and obtains an assertion that all patches are now installed.
企业管理员提供补丁，并更改网络策略，要求在下午5点之前安装补丁。此策略更改会导致NEA服务器请求重新评估，以确定哪些端点受到影响且缺少修补程序。市场部员工的笔记本电脑经过重新评估并确定需要修补程序。向员工发送并提交补救建议，说明如何获取修补程序，以及必须在下午5点之前安装修补程序。营销员工立即下载并安装修补程序，并获得所有修补程序现在已安装的断言。
At 5 PM, the enterprise performs another reassessment of all impacted endpoints to determine if they are now in compliance. The marketing employee's laptop is reassessed and presents the assertion that it has the patches installed and thus is determined to be compliant.
下午5点，企业对所有受影响的端点执行另一次重新评估，以确定它们是否符合要求。对营销员工的笔记本电脑进行重新评估，并声明其已安装补丁，因此被确定为符合要求。
The following describes the message flows through the NEA reference model for the above example:
以下描述了通过上述示例的NEA参考模型的消息流：
1. Marketing employee joins network and completes an initial assessment resulting in a compliant decision.
1. 营销部员工加入网络并完成初始评估，从而做出符合要求的决策。
2. The Enterprise Administrator configures an operating system patch policy indicating that recent patches are required on all endpoints by 5 PM to prevent serious vulnerabilities.
2. 企业管理员配置操作系统修补程序策略，指示在下午5点之前所有端点上都需要最新的修补程序，以防止出现严重漏洞。
3. The NEA Server's operating system patch Posture Validator becomes aware of this policy change and creates a PA message requesting attributes describing OS patches in use and triggers the Posture Broker Server to initiate a posture reassessment of all endpoints connected to the network.
3. NEA服务器的操作系统补丁姿态验证器意识到此策略更改，并创建PA消息，请求描述正在使用的操作系统补丁的属性，并触发姿态代理服务器启动连接到网络的所有端点的姿态重新评估。
4. The Posture Broker creates a PB message that includes the PA message from the operating system patch Posture Validator.
4. 姿态代理创建一条PB消息，其中包括来自操作系统补丁姿态验证程序的PA消息。
5. The Posture Broker Server gradually establishes a session with each available NEA Client.
5. The Posture Broker Server gradually establishes a session with each available NEA Client.translate error, please retry
6. The Posture Broker Server sends the PB message to the Posture Broker Client.
6. 姿态代理服务器向姿态代理客户端发送PB消息。
7. The Posture Transport Server carries the PB message to the Posture Transport Client over the PT protocol.
7. 姿态传输服务器通过PT协议将PB消息传送到姿态传输客户端。
8. The Posture Broker Client receives the PB message and forwards the PA message to the operating system patch Posture Collector.
8. 姿态代理客户端接收PB消息并将PA消息转发给操作系统补丁姿态收集器。
9. The operating system patch Posture Collector determines the OS patches present on the endpoint and if authorized by its disclosure policy creates a PA message containing the patch information attributes.
9. 操作系统补丁姿态收集器确定端点上存在的操作系统补丁，如果其公开策略授权，将创建包含补丁信息属性的PA消息。
10. The Posture Broker Client sends a PB message that includes the operating system patch PA message.
10. 姿态代理客户端发送包含操作系统补丁PA消息的PB消息。
11. The Posture Transport Client transports the PB message to the Posture Transport Server where it is passed to the Posture Broker Server.
11. 姿态传输客户端将PB消息传输到姿态传输服务器，并将其传递到姿态代理服务器。
12. The Posture Broker Server receives the PB message and delivers the PA message to the operating system patch Posture Validator.
12. 姿态代理服务器接收PB消息，并将PA消息传递给操作系统补丁姿态验证器。
13. The operating system patch Posture Validator extracts the attributes describing the current OS patches from the PA message and uses the values to determine whether the endpoint is compliant with the new policy. The Posture Validator determines that the endpoint is not compliant since it does not have the new OS patches installed.
13. 操作系统补丁姿态验证器从PA消息中提取描述当前操作系统补丁的属性，并使用这些值确定端点是否符合新策略。姿态验证器确定端点不兼容，因为它没有安装新的操作系统补丁。
14. The Posture Validator generates a PA message that includes attributes stating the posture assessment decision is non-compliant and attributes containing the remediation instructions to enable the endpoint to download the required OS patches.
14. 姿态验证器生成一条PA消息，该消息包括声明姿态评估决策不符合要求的属性和包含修正指令的属性，以使端点能够下载所需的操作系统补丁。
15. The Posture Validator communicates the posture assessment result to the Posture Broker Server along with its PA message.
15. 姿势验证器将姿势评估结果与其PA消息一起传递给姿势代理服务器。
16. The Posture Broker Server generates a global assessment decision and sends a PB message with the decision and the operating system patch Posture Validator's PA message.
16. 姿态代理服务器生成一个全局评估决策，并发送带有该决策的PB消息和操作系统补丁姿态验证器的PA消息。
17. The Posture Transport Server transports the PB message to the Posture Transport Client where it is passed to the Posture Broker Client.
17. 姿态传输服务器将PB消息传输到姿态传输客户端，并将其传递到姿态代理客户端。
18. The Posture Broker Client processes the Result Attribute received from the NEA Server and displays the non-compliance decision to the user.
18. 姿态代理客户端处理从NEA服务器接收的结果属性，并向用户显示不合规决策。
19. The Posture Broker Client forwards the PA message containing the remediation instructions to the operating system patch Posture Collector; the Posture Collector guides the user with instructions on how to become compliant that include downloading the appropriate OS patches to prevent the vulnerability.
19. 姿态代理客户端将包含修正指令的PA消息转发给操作系统补丁姿态收集器；姿态收集器为用户提供有关如何做到兼容的说明，包括下载适当的操作系统补丁以防止该漏洞。
20. The marketing employee installs the required patches and now is in compliance.
20. 营销部员工安装了所需的修补程序，现在符合要求。
21. The NEA Client triggers a reassessment of the operating system patches that causes a repeat of many of the steps above. This time, in step 13 the operating system patch Posture Validator determines the marketing employee's laptop is compliant. It returns a reusable (e.g., signed and dated) set of attributes that assert OS patch compliance to the latest policy. These OS patch compliance assertions can be used in a future PA message from the operating system patch Collector instead of determining and providing the specific patch set posture as before.
21. NEA客户端触发对操作系统修补程序的重新评估，导致重复上述许多步骤。这一次，在步骤13中，操作系统补丁姿态验证器确定营销员工的笔记本电脑符合要求。它返回一组可重复使用（例如，签名和注明日期）的属性，这些属性可断言操作系统补丁是否符合最新策略。这些操作系统修补程序符合性断言可以在将来来自操作系统修补程序收集器的PA消息中使用，而不是像以前那样确定和提供特定的修补程序集姿态。
22. This time when the operating system patch Posture Collector receives the PA message that contains reusable attributes asserting compliance, it caches those attributes for future use.
22. 这一次，当操作系统补丁姿态收集器接收到包含可重用属性的PA消息时，它会缓存这些属性以备将来使用。
23. Later at 5 PM, the NEA Server triggers a gradual reassessment to determine compliance to the patch advisory. When the operating system patch Posture Collector receives the request for posture information (like in step 9 above) it returns the cached set of assertions (instead of specific OS patch information) to indicate that the patches have been installed instead of determining all the patches that have been installed on the system.
23. 下午5点晚些时候，NEA服务器触发逐步重新评估，以确定是否符合修补程序建议。当操作系统补丁姿态收集器接收到姿态信息请求时（如上面的步骤9），它返回缓存的断言集（而不是特定的操作系统补丁信息），以指示补丁已经安装，而不是确定系统上已经安装的所有补丁。
24. When the operating system patch Posture Validator receives the PA message containing the assertions, it is able to determine that they are authentic and acceptable assertions instead of specific posture. It returns a posture assessment decision of compliant thus allowing the laptop to remain on the network.
24. 当操作系统补丁姿态验证器接收到包含断言的PA消息时，它能够确定它们是真实的和可接受的断言，而不是特定的姿态。它返回一个符合的姿势评估决定，从而允许笔记本电脑留在网络上。
The following are several different aspects of the use case example that potentially need to be factored into the requirements.
下面是用例示例的几个不同方面，这些方面可能需要考虑到需求中。
o Server-initiated reassessment required due to urgent patch availability
o 由于紧急补丁可用，需要服务器启动重新评估
o NEA Client submits reusable assertion attributes instead of posture that patch is installed
o NEA客户端提交可重用的断言属性，而不是安装补丁的姿态
o NEA Server capable of recognizing previously issued assertion attributes are sufficient instead of posture
o 能够识别先前发布的断言属性而不是姿态的NEA服务器就足够了
This section describes the requirements that will be used by the NEA WG to assess and compare candidate protocols for PA, PB, and PT. These requirements frequently express features that a candidate protocol must be capable of offering so that a deployer can decide whether to make use of that feature. This section does not state requirements about what features of each protocol must be used during a deployment.
本节描述了NEA工作组用于评估和比较PA、PB和PT候选协议的要求。这些需求通常表示候选协议必须能够提供的特性，以便部署人员可以决定是否使用该特性。本节不说明部署期间必须使用每个协议的哪些功能的要求。
For example, a requirement (MUST, SHOULD, or MAY) might exist for cryptographic security protections to be available from each protocol but this does not require that a deployer make use of all or even any of them should they deem their environment to offer other protections that are sufficient.
例如，可能存在一个要求（必须、应该或可能），要求每个协议都提供加密安全保护，但这并不要求部署人员在他们认为自己的环境能够提供足够的其他保护时使用所有或甚至任何加密安全保护。
The following are the common requirements that apply to the PA, PB, and PT protocols in the NEA reference model:
以下是适用于NEA参考模型中PA、PB和PT协议的通用要求：
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服务器之间的多次往返。
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服务器提供一种方式，以便根据需要启动姿势评估或重新评估。
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协议（包括安全功能）必须能够防止中介和端点的主动和被动攻击，包括防止基于重播的攻击。
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, TLS, and Internet Key Exchange Protocol version 2 (IKEv2)).
C-4 PA和PB协议必须能够在任何PT协议上运行。例如，PB协议必须提供一个独立于传输的接口，允许PA协议在各种网络协议环境（例如EAP/802.1X、TLS和Internet密钥交换协议版本2（IKEv2））中无需更改即可运行。
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的目标不是在已经存在可接受解决方案的情况下创建其他替代协议。
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服务器上的多个姿态验证器进行评估。
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服务器之间高效传输大量属性消息。
C-8 NEA protocols MUST operate efficiently over low bandwidth or high latency links.
C-8 NEA协议必须在低带宽或高延迟链路上高效运行。
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对于打算向用户显示的任何字符串，协议必须支持根据用户的语言偏好调整这些字符串。
C-10 NEA protocols MUST support encoding of strings in UTF-8 format [UTF8].
C-10 NEA协议必须支持UTF-8格式[UTF8]的字符串编码。
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 roundtrips, 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协议施加的限制。
The Posture Attribute (PA) protocol defines the transport and data model to carry posture and validation information between a particular Posture Collector associated with the NEA Client and a Posture Validator associated with a NEA Server. The PA protocol carries collections of standard attributes and vendor-specific attributes. The PA protocol itself is carried inside the PB protocol.
姿态属性（PA）协议定义了传输和数据模型，用于在与NEA客户端关联的特定姿态采集器和与NEA服务器关联的姿态验证器之间传输姿态和验证信息。PA协议包含标准属性和供应商特定属性的集合。PA协议本身包含在PB协议中。
The following requirements define the desired properties that form the basis for comparison and evaluation of candidate PA protocols. These requirements do not mandate the use of these properties, but merely that the candidate protocols are capable of offering the property if it should be needed.
以下要求定义了构成候选PA协议比较和评估基础的所需特性。这些要求并不要求使用这些属性，只是要求候选协议能够在需要时提供属性。
PA-1 The PA protocol MUST support communication of an extensible set of NEA standards defined attributes. These attributes will be distinguishable from non-standard attributes.
PA-1 PA协议必须支持一组可扩展的NEA标准定义属性的通信。这些属性将与非标准属性区分开来。
PA-2 The PA protocol MUST support communication of an extensible set of vendor-specific attributes. These attributes will be segmented into uniquely identified vendor-specific namespaces.
PA-2 PA协议必须支持一组可扩展的供应商特定属性的通信。这些属性将被分割为唯一标识的特定于供应商的名称空间。
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-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-5 The PA protocol SHOULD provide authentication, integrity, and confidentiality protection for 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-6 The PA protocol MUST be capable of carrying attributes that contain non-binary and binary data including encrypted content.
PA-6 PA协议必须能够承载包含非二进制和二进制数据（包括加密内容）的属性。
The PB protocol supports multiplexing of Posture Attribute messages (based on PA protocol) between the Posture Collectors on the NEA Client to and from the Posture Validators on the NEA Server (in either direction).
PB协议支持在NEA客户端上的姿态采集器与NEA服务器上的姿态验证器之间（在任意方向）复用姿态属性消息（基于PA协议）。
The PB protocol carries the global assessment decision made by the Posture Broker Server, taking into account the results of the Posture Validators involved in the assessment, to the Posture Broker Client.
PB协议将姿态代理服务器做出的全局评估决策（考虑到评估中涉及的姿态验证器的结果）传送到姿态代理客户端。
The PB protocol also aggregates and transports advisories and notifications such as remediation instructions (e.g., patch references) from one or more Posture Validators.
PB协议还聚合和传输来自一个或多个姿势验证器的建议和通知，如补救说明（例如，补丁引用）。
The requirements for the PB protocol are:
PB协议的要求如下：
PB-1 The PB protocol MUST be capable of carrying attributes from the Posture Broker Server to the Posture Broker Client. This enables the Posture Broker Client to learn the posture assessment decision and if appropriate to aid in remediation and notification of the endpoint owner.
PB-1 PB协议必须能够将属性从姿态代理服务器传输到姿态代理客户端。这使姿态代理客户端能够了解姿态评估决策，并在适当时帮助修复和通知端点所有者。
PB-2 The PB protocol MUST NOT interpret the contents of PA messages being carried, i.e., the data it is carrying must be opaque to it.
PB-2 PB协议不得解释所承载PA消息的内容，即所承载的数据必须对其不透明。
PB-3 The PB protocol MUST carry unique identifiers that are used by the Posture Brokers to route (deliver) PA messages between Posture Collectors and Posture Validators. Such message routing should facilitate dynamic registration or deregistration of Posture Collectors and Validators. For example, a dynamically registered anti-virus Posture Validator should be able to subscribe to receive messages from its respective anti-virus Posture Collector on NEA Clients.
PB-3 PB协议必须携带姿势代理用于在姿势收集器和姿势验证器之间路由（传递）PA消息的唯一标识符。这种消息路由应该有助于姿态收集器和验证器的动态注册或注销。例如，动态注册的防病毒姿态验证器应该能够订阅以从NEA客户端上的相应防病毒姿态收集器接收消息。
PB-4 The PB protocol MUST be capable of supporting a half-duplex PT protocol. However this does not preclude PB from operating full-duplex when running over a full-duplex PT.
PB-4 PB协议必须能够支持半双工PT协议。然而，这并不妨碍PB在全双工PT上运行时操作全双工。
PB-5 The PB protocol MAY support authentication, integrity and confidentiality protection for the attribute messages it carries between a Posture Broker Client and Posture Broker Server. This provides security protection for a message dialog of the groupings of attribute messages exchanged between the Posture Broker Client and Posture Broker Server. Such protection is orthogonal to PA protections (which are end to end) and allows for simpler Posture Collector and Validators to be implemented, and for consolidation of cryptographic operations possibly improving scalability and manageability.
PB-5 PB协议可支持在姿态代理客户端和姿态代理服务器之间传输的属性消息的身份验证、完整性和机密性保护。这为姿态代理客户端和姿态代理服务器之间交换的属性消息分组的消息对话框提供了安全保护。这种保护与PA保护（端到端）正交，允许实现更简单的姿态收集器和验证器，并允许整合加密操作，可能提高可伸缩性和可管理性。
PB-6 The PB protocol MUST support grouping of attribute messages optimize transport of messages and minimize round trips.
PB-6 PB协议必须支持属性消息分组，优化消息传输并最小化往返。
The Posture Transport (PT) protocol carries PB protocol messages between the Posture Transport Client and the Posture Transport Server. PT is responsible for providing a protected transport for the PB protocol. The PT protocol may itself be transported by one or more concatenated sessions using lower layer protocols, such as 802.1X, RADIUS [RADIUS], TLS, or IKE.
姿态传输（PT）协议在姿态传输客户端和姿态传输服务器之间传输PB协议消息。PT负责为PB协议提供受保护的传输。PT协议本身可以通过使用较低层协议（例如802.1X、RADIUS[RADIUS]、TLS或IKE）的一个或多个级联会话来传输。
This section defines the requirements that candidate PT protocols must be capable of supporting.
本节定义了候选PT协议必须能够支持的要求。
PT-1 The PT protocol MUST NOT interpret the contents of PB messages being transported, i.e., the data it is carrying must be opaque to it.
PT-1 PT协议不得解释正在传输的PB消息的内容，即，它所承载的数据对它来说必须是不透明的。
PT-2 The PT protocol MUST be capable of supporting mutual authentication, integrity, confidentiality, and replay protection of the PB messages between the Posture Transport Client and the Posture Transport Server.
PT-2 PT协议必须能够支持姿态传输客户端和姿态传输服务器之间PB消息的相互认证、完整性、机密性和重播保护。
PT-3 The PT protocol MUST provide reliable delivery for the PB protocol. This includes the ability to perform fragmentation and reassembly, detect duplicates, and reorder to provide in-sequence delivery, as required.
PT-3 PT协议必须为PB协议提供可靠的交付。这包括根据需要执行分段和重新组装、检测重复项和重新排序以提供顺序交付的能力。
PT-4 The PT protocol SHOULD be able to run over existing network access protocols such as 802.1X and IKEv2.
PT-4 PT协议应能够在现有网络接入协议（如802.1X和IKEv2）上运行。
PT-5 The PT protocol SHOULD be able to run between a NEA Client and NEA Server over TCP or UDP (similar to Lightweight Directory Access Protocol (LDAP)).
PT-5 PT协议应能够通过TCP或UDP（类似于轻型目录访问协议（LDAP））在NEA客户端和NEA服务器之间运行。
This document defines the functional requirements for the PA, PB, and PT protocols used for Network Endpoint Assessment. As such, it does not define a specific protocol stack or set of technologies, so this section will highlight security issues that may apply to NEA in general or to particular aspects of the NEA reference model.
本文件定义了用于网络端点评估的PA、PB和PT协议的功能要求。因此，它没有定义特定的协议栈或技术集，因此本节将重点介绍可能适用于NEA一般或NEA参考模型特定方面的安全问题。
Note that while a number of topics are outside the scope of the NEA WG and thus this specification (see section 3.1), it is important that those mechanisms are protected from attack. For example, the methods of triggering an assessment or reassessment are out of scope but should be appropriately protected from attack (e.g., an attacker hiding the event indicating a NEA Server policy change has occurred).
请注意，虽然许多主题不在NEA工作组的范围内，因此本规范（见第3.1节），但重要的是保护这些机制免受攻击。例如，触发评估或重新评估的方法超出范围，但应受到适当的保护，以防受到攻击（例如，攻击者隐藏表明发生了NEA服务器策略更改的事件）。
NEA intends to facilitate detection and corrective actions for cooperating endpoints to become compliant with network compliance policies. For example, it is envisioned that these policies will allow deployers to detect out-of-date, inactive, or absent security mechanisms on the endpoint that might leave it more vulnerable to known attacks. If an endpoint is more vulnerable to compromise, then it is riskier to have this endpoint present on the network with other valuable assets. By proactively assessing cooperating endpoints before their entrance to the network, deployers can improve their resilience to attack prior to network access. Similarly, reassessments of cooperating endpoints on the network may be helpful in assuring that security mechanisms remain in use and are up to date with the latest policies.
NEA打算促进合作端点的检测和纠正措施，以符合网络合规政策。例如，可以预见，这些策略将允许部署人员在端点上检测过期、不活动或缺失的安全机制，这些机制可能使端点更容易受到已知攻击。如果一个端点更容易受到危害，那么将该端点与其他有价值的资产一起出现在网络上的风险就更大。通过在合作端点进入网络之前主动评估这些端点，部署人员可以在网络访问之前提高其抵御攻击的能力。类似地，重新评估网络上的协作端点可能有助于确保安全机制仍在使用，并且是最新策略的最新版本。
NEA fully recognizes that not all endpoints will be cooperating by providing their valid posture (or any posture at all). This might occur if malware is influencing the NEA Client or policies, and thus a trustworthy assessment isn't possible. Such a situation could result in the admission of an endpoint that introduces threats to the network and other endpoints despite passing the NEA compliance assessment.
NEA充分认识到，并非所有端点都会通过提供其有效姿势（或任何姿势）进行合作。如果恶意软件影响NEA客户端或策略，因此无法进行可信评估，则可能会发生这种情况。这种情况可能导致接纳一个端点，该端点对网络和其他端点造成威胁，尽管通过了NEA合规性评估。
Network Endpoint Assessment involves assessing the posture of endpoints entering or already on the network against compliance policies to assure they are adequately protected. Therefore, there must be an implied distrusting of endpoints until there is reason to believe (based on posture information) that they are protected from threats addressed by compliance policy and can be trusted to not propagate those threats to other endpoints. On the network provider side, the NEA Client normally is expected to trust the network infrastructure systems to not misuse any disclosed posture information (see section 9) and any remediation instructions provided to the endpoint. The NEA Client normally also needs to trust that the NEA Server will only request information required to determine whether the endpoint is safe to access the network assets.
网络端点评估涉及根据合规政策评估进入或已经在网络上的端点的状态，以确保它们得到充分保护。因此，必须隐含对端点的不信任，直到有理由相信（基于态势信息）端点受到保护，不受法规遵从性策略所述威胁的影响，并且可以信任端点不会将这些威胁传播到其他端点。在网络提供商方面，NEA客户端通常会信任网络基础设施系统不会误用任何披露的姿态信息（见第9节）以及向端点提供的任何补救说明。NEA客户端通常还需要相信NEA服务器将只请求确定端点访问网络资产是否安全所需的信息。
Between the NEA Client and Server there exists a network that is not assumed to be trustworthy. Therefore, little about the network is implicitly trusted beyond its willingness and ability to transport the exchanged messages in a timely manner. The amount of trust given to each component of the NEA reference model is deployment specific. The NEA WG intends to provide security mechanisms to reduce the amount of trust that must be assumed by a deployer. The following sections will discuss each area in more detail.
NEA客户端和服务器之间存在一个不被认为是可信的网络。因此，除了愿意和能够及时地传输交换的消息之外，网络几乎没有什么隐含的信任。给予NEA参考模型每个组件的信任量是特定于部署的。NEA工作组打算提供安全机制，以减少部署人员必须承担的信任量。以下各节将更详细地讨论每个领域。
For NEA to properly operate, the endpoint needs to be trusted to accurately represent the requested security posture of the endpoint to the NEA Server. By NEA WG charter, the NEA reference model does not explicitly specify how to detect or prevent lying endpoints that intentionally misrepresent their posture. Similarly, the detection of malware (e.g., root kits) that are able to trick the Posture Collectors into returning incorrect information is the subject for research and standardization outside the IETF (e.g., Trusted Computing Group [TCG]) and is not specifically addressed by the model. However, if such mechanisms are used in a deployment, the NEA reference model should be able to accommodate these technologies by allowing them to communicate over PA to Posture Validators or work orthogonally to protect the NEA Client from attack and assure the ability of Posture Collectors to view the actual posture.
为了使NEA正常运行，需要信任端点，以便准确地向NEA服务器表示端点请求的安全态势。根据NEA工作组章程，NEA参考模型未明确规定如何检测或防止故意歪曲其姿势的躺着端点。类似地，检测能够诱使姿态采集器返回错误信息的恶意软件（例如，根工具包）是IETF（例如，可信计算组[TCG]）之外的研究和标准化主题，该模型并未具体解决。然而，如果在部署中使用此类机制，NEA参考模型应能够通过允许这些技术通过PA与姿势验证器通信或正交工作来适应这些技术，以保护NEA客户端免受攻击，并确保姿势采集器查看实际姿势的能力。
Besides having to trust the integrity of the NEA Client and its ability to accurately collect and report Posture Attributes about the endpoint, we try to limit other assumed trust. Most of the usage models for NEA expect the posture information to be sent to the NEA Server for evaluation and decision making. When PA and/or PT level security protections are used, the endpoint needs to trust the integrity and potentially confidentiality of the trust anchor information (e.g., public key certificates) used by the Posture Collector and/or Posture Transport Client. However, NEA implementations may choose to send or pre-provision some policies to the endpoint for evaluation that would assume more trust in the endpoint. In this case, the NEA Server must trust the endpoint's policy storage, evaluation, and reporting mechanisms to not falsify the results of the posture evaluation.
除了必须信任NEA客户端的完整性及其准确收集和报告端点姿态属性的能力外，我们还试图限制其他假定的信任。NEA的大多数使用模型都希望将姿势信息发送到NEA服务器进行评估和决策。当使用PA和/或PT级安全保护时，端点需要信任姿态收集器和/或姿态传输客户端使用的信任锚信息（例如公钥证书）的完整性和潜在机密性。但是，NEA实现可能会选择向端点发送或预先提供一些策略，以进行评估，从而假定对端点的信任度更高。在这种情况下，NEA服务器必须信任端点的策略存储、评估和报告机制，以避免伪造姿势评估的结果。
Generally the endpoint should not trust network communications (e.g., inbound connection requests) unless this trust has been specifically authorized by the user or owner defined policy or action. The NEA reference model assumes the entire NEA Client is local to the endpoint. Unsolicited communications originating from the network should be inspected by normal host-based security protective mechanisms (e.g., firewalls, security protocols, Intrusion Detection/Prevention System (IDS/IPS), etc.). Communications associated with a NEA assessment or reassessment requires some level of trust particularly when initiated by the NEA Server (reassessment). The degree of trust can be limited by use of strong security protections on the messages as dictated by the network deployer and the endpoint user/owner policy.
通常，端点不应信任网络通信（例如，入站连接请求），除非此信任已由用户或所有者定义的策略或操作专门授权。NEA参考模型假设整个NEA客户端位于端点的本地。应通过基于主机的正常安全保护机制（如防火墙、安全协议、入侵检测/预防系统（IDS/IPS）等）检查来自网络的未经请求的通信。与NEA评估或重新评估相关的通信需要一定程度的信任，尤其是由NEA服务器发起时（重新评估）。根据network deployer和端点用户/所有者策略的规定，对消息使用强大的安全保护可以限制信任度。
Between the NEA Client and Server, there may exist a variety of types of devices to facilitate the communication path. Some of the devices may serve as intermediaries (e.g., simple L2 switches) so they may have the opportunity to observe and change the message dialogs.
在NEA客户端和服务器之间，可能存在各种类型的设备以促进通信路径。一些设备可以作为中介（例如，简单的二级交换机），因此它们可能有机会观察和更改消息对话框。
The intermediary devices may fall into a few major categories that impact our degree of trust in their operation. First, some intermediary devices may act as message forwarders or carriers for PT (e.g., L2 switches, L3 routers). For these devices we trust them not to drop the messages or actively attempt to disrupt (e.g., denial of service (DoS)) the NEA deployment.
中介机构可能会分为几个主要类别，影响我们对其运作的信任程度。首先，一些中间设备可以充当PT的消息转发器或载波（例如，L2交换机、L3路由器）。对于这些设备，我们相信它们不会丢弃消息或主动尝试中断（例如，拒绝服务（DoS））NEA部署。
Second, some intermediary devices may be part of the access control layer of the network and as such, we trust them to enforce policies including remediation, isolation, and access controls given to them as a result on a NEA assessment. These devices may also fill other types of roles described in this section.
第二，一些中间设备可能是网络访问控制层的一部分，因此，我们相信他们会执行政策，包括根据NEA评估结果给予他们的补救、隔离和访问控制。这些设备还可以担任本节中描述的其他类型的角色。
Third, some devices may act as a termination point or proxy for the PT carrier protocol. Frequently, it is expected that the carrier protocol for PT will terminate on the NEA Client and Server so will be co-resident with the PT endpoints. If this expectation is not present in a deployment, we must trust the termination device to accurately proxy the PT messages without alteration into the next carrier protocol (e.g., if inner EAP method messages are transitioned from an EAP [EAP] tunnel to a RADIUS session).
第三，一些设备可以充当PT载波协议的终止点或代理。通常，预计PT的载波协议将在NEA客户端和服务器上终止，因此将与PT端点共存。如果部署中不存在这种期望，我们必须信任终端设备准确地代理PT消息，而不会更改为下一个载波协议（例如，如果内部EAP方法消息从EAP[EAP]隧道转换为RADIUS会话）。
Fourth, many networks include infrastructure such as IDS/IPS devices that monitor and take corrective action when suspicious behavior is observed on the network. These devices may have a relationship with the NEA Server that is not within scope for this specification. Devices trusted by the NEA Server to provide security information that might affect the NEA Server's decisions are trusted to operate properly and not cause the NEA Server to make incorrect decisions.
第四，许多网络包括IDS/IPS设备等基础设施，当在网络上观察到可疑行为时，这些设备会进行监控并采取纠正措施。这些设备可能与NEA服务器存在不在本规范范围内的关系。NEA服务器信任提供可能影响NEA服务器决策的安全信息的设备可以正常运行，不会导致NEA服务器做出错误决策。
Finally, other types of intermediary devices may exist on the network between the NEA Client and Server that are present to service other network functions beside NEA. These devices might be capable of passively eavesdropping on the network, archiving information for future purposes (e.g., replay or privacy invasion), or more actively attacking the NEA protocols. Because these devices do not play a role in facilitating NEA, it is essential that NEA deployers not be forced to trust them for NEA to reliably operate. Therefore, it is required that NEA protocols offer security protections to assure these devices can't steal, alter, spoof or otherwise damage the reliability of the message dialogs.
最后，NEA客户端和服务器之间的网络上可能存在其他类型的中间设备，这些设备用于服务NEA之外的其他网络功能。这些设备可能能够在网络上进行被动窃听、存档信息以备将来使用（例如，重播或隐私入侵），或者更主动地攻击NEA协议。由于这些设备在促进NEA方面不起作用，因此NEA部署人员不必被迫信任这些设备，以便NEA可靠运行。因此，需要NEA协议提供安全保护，以确保这些设备不会窃取、更改、欺骗或以其他方式损坏消息对话框的可靠性。
The NEA Server (including potentially remote systems providing posture validation services) is generally trusted to apply the specified assessment policies and must be protected from compromise. It is essential that NEA Server deployments properly safeguard these systems from a variety of attacks from the network and endpoints to assure their proper operation.
NEA服务器（包括提供姿势验证服务的潜在远程系统）通常可以应用指定的评估策略，并且必须受到保护，以免受到危害。NEA服务器部署必须正确保护这些系统免受来自网络和端点的各种攻击，以确保其正常运行。
While there is a need to trust the NEA Server operation to some degree, rigorous security architecture, analysis, monitoring, and review should assure its network footprint and internal workings are protected from attack. The network footprint would include communications over the network that might be subject to attack such as policy provisioning from the policy authoring systems and general security and system management protocols. Some examples of internal workings include protections from malware attacking the intra-NEA Server communications, NEA Server internal logic, or policy stores (particularly those that would change the resulting decisions or enforcements). The NEA Server needs to trust the underlying NEA and lower layer network protocols to properly behave and safeguard the exchanged messages with the endpoint. The NEA reference model does not attempt to address integrity protection of the operating system or other software supporting the NEA Server.
虽然需要在一定程度上信任NEA服务器操作，但严格的安全体系结构、分析、监控和审查应确保其网络足迹和内部工作免受攻击。网络覆盖范围将包括可能受到攻击的网络通信，如来自策略编写系统和一般安全和系统管理协议的策略提供。内部工作的一些示例包括防止恶意软件攻击NEA服务器内部通信、NEA服务器内部逻辑或策略存储（特别是那些会改变最终决定或执行的）。NEA服务器需要信任底层NEA和较低层网络协议，以正确运行并保护与端点交换的消息。NEA参考模型不试图解决支持NEA服务器的操作系统或其他软件的完整性保护问题。
One interesting example is where some components of the NEA Server physically reside in different systems. This might occur when a Posture Validator (or a remote backend server used by a local Posture Validator) exists on another system from the Posture Broker Server. Similarly, the Posture Broker Server might exist on a separate system from the Posture Transport Server. When there is a physical separation, the communications between the remote components of the NEA Server must ensure that the PB session and PA message dialogs are resistant to active and passive attacks, in particular, guarded against eavesdropping, forgery and replay. Similarly, the Posture Validators may also wish to minimize their trust in the Posture Broker Server beyond its ability to properly send and deliver PA messages. The Posture Validators could employ end-to-end PA security to verify the authenticity and protect the integrity and/or confidentiality of the PA messages exchanged.
一个有趣的例子是，NEA服务器的某些组件实际驻留在不同的系统中。当姿态验证程序（或本地姿态验证程序使用的远程后端服务器）存在于姿态代理服务器的另一个系统上时，可能会发生这种情况。类似地，姿态代理服务器可能存在于与姿态传输服务器不同的系统上。当存在物理隔离时，NEA服务器远程组件之间的通信必须确保PB会话和PA消息对话框能够抵抗主动和被动攻击，特别是防止窃听、伪造和重播。类似地，姿态验证器还可能希望将其对姿态代理服务器的信任降至最低，使其无法正确发送和传递PA消息。姿态验证器可以使用端到端PA安全性来验证真实性，并保护所交换PA消息的完整性和/或机密性。
When PA security is used, each Posture Validator must be able to trust the integrity and potentially confidentiality of its trust anchor policies.
使用PA安全性时，每个姿态验证器必须能够信任其信任锚策略的完整性和潜在机密性。
Inherent in the requirements is a desire for NEA candidate protocols throughout the reference model to be capable of providing strong security mechanisms as dictated by the particular deployment. In some cases, these mechanisms may appear to provide overlapping or redundant protections. These apparent overlaps may be used in combination to offer a defense in depth approach to security. However, because of the layering of the protocols, each set of protections offers slightly different benefits and levels of granularity.
需求中固有的一个愿望是，整个参考模型中的NEA候选协议能够根据特定部署提供强大的安全机制。在某些情况下，这些机制可能提供重叠或冗余保护。这些明显的重叠可以结合使用，以提供安全性的纵深防御方法。但是，由于协议的分层，每组保护提供的好处和粒度级别略有不同。
For example, a deployer may wish to encrypt traffic at the PT layer to protect against some forms of traffic analysis or interception by an eavesdropper. Additionally, the deployer may also selectively encrypt messages containing the posture of an endpoint to achieve end-to-end confidentiality to its corresponding Posture Validator. In particular, this might be desired when the Posture Validator is not co-located with the NEA Server so the information will traverse additional network segments after the PT protections have been enforced or so that the Posture Validator can authenticate the corresponding Posture Collector (or vice versa).
例如，部署者可能希望在PT层加密流量，以防止窃听者进行某种形式的流量分析或拦截。此外，部署者还可以选择性地加密包含端点姿态的消息，以实现对其相应姿态验证器的端到端机密性。特别是，当姿态验证器与NEA服务器不在同一位置时，这可能是需要的，这样信息将在PT保护实施后穿过其他网段，或者姿态验证器可以验证相应的姿态采集器（反之亦然）。
Different use cases and environments for the NEA technologies will likely influence the selection of the strength and security mechanisms employed during an assessment. The goal of the NEA requirements is to encourage the selection of technologies and protocols that are capable of providing the necessary protections for a wide variety of types of assessment.
NEA技术的不同使用案例和环境可能会影响评估期间使用的强度和安全机制的选择。NEA要求的目标是鼓励选择能够为各种类型的评估提供必要保护的技术和协议。
A variety of attacks are possible against the NEA protocols and assessment technologies. This section does not include a full security analysis, but wishes to highlight a few attacks that influenced the requirement definition and should be considered by deployers selecting use of protective mechanisms within the NEA reference model.
针对NEA协议和评估技术的各种攻击都是可能的。本节不包括完整的安全分析，但希望强调一些影响需求定义的攻击，部署人员在选择使用NEA参考模型中的保护机制时应考虑这些攻击。
As discussed, there are a variety of protective mechanisms included in the requirements for candidate NEA protocols. Different use cases and environments may cause deployers to decide not to use some of these mechanisms; however, this should be done with an understanding that the deployment may become vulnerable to some classes of attack. As always, a balance of risk vs. performance, usability, manageability, and other factors should be taken into account.
如前所述，候选NEA协议的要求中包括各种保护机制。不同的用例和环境可能会导致部署人员决定不使用其中一些机制；但是，在执行此操作时，应了解部署可能容易受到某些类别的攻击。一如既往，风险与性能、可用性、可管理性和其他因素之间的平衡应该得到考虑。
The following types of attacks are applicable to network protocols defined in the reference model and thus should be considered by deployers.
以下类型的攻击适用于参考模型中定义的网络协议，因此部署人员应予以考虑。
MITM attacks against a network protocol exist when a third party can insert itself between two communicating entities without detection and gain benefit from involvement in their message dialog. For example, a malware infested system might wish to join the network replaying posture observed from a clean endpoint entering the network. This might occur by the system inserting itself into and actively proxying an assessment message dialog. The impact of the damage caused by the MITM can be limited or prevented by selection of appropriate protocol protective mechanisms.
当第三方可以在两个通信实体之间插入自身而无需检测并从参与其消息对话中获益时，就会存在针对网络协议的MITM攻击。例如，受恶意软件感染的系统可能希望加入网络，并从进入网络的干净端点处观察重播姿势。系统将自身插入并主动代理评估消息对话框可能会发生这种情况。通过选择适当的协议保护机制，可以限制或防止MITM造成的损害的影响。
For example, the requirement for PT to be capable of supporting mutual authentication prior to any endpoint assessment message dialogs prevents the attacker from inserting itself as an active participant (proxy) within the communications without detection (assuming the attacker lacks credentials convincing either party it is legitimate). Reusable credentials should not be exposed on the network to assure the MITM doesn't have a way to impersonate either party. The PT requirement for confidentiality-protected (encrypted) communications linked to the above authentication prevents a passive MITM from eavesdropping by observing the message dialog and keeping a record of the conformant posture values for future use. The PT requirement for replay prevention stops a passive MITM from later establishing a new session (or hijacking an existing session) and replaying previously observed message dialogs.
例如，要求PT能够在任何端点评估消息对话框之前支持相互身份验证，从而防止攻击者在未经检测的情况下将自己作为活动参与者（代理）插入通信中（假设攻击者缺乏使任何一方确信其合法的凭据）。不应在网络上公开可重用凭据，以确保MITM没有办法模拟任何一方。与上述身份验证相关的保密（加密）通信的PT要求通过观察消息对话框并记录一致姿态值以备将来使用，防止被动MITM窃听。防止重播的PT要求阻止被动MITM稍后建立新会话（或劫持现有会话）并重播以前观察到的消息对话框。
If a non-compliant, active MITM is able to trick a clean endpoint to give up its posture information, and the MITM has legitimate credentials, it might be able to appear to a NEA Server as having compliant posture when it does not. For example, a non-compliant MITM could connect and authenticate to a NEA Server and as the NEA Server requests posture information, the MITM could request the same posture from the clean endpoint. If the clean endpoint trusts the MITM to perform a reassessment and is willing to share the requested posture, the MITM could obtain the needed posture from the clean endpoint and send it to the NEA Server. In order to address this form of MITM attack, the NEA protocols would need to offer a strong (cryptographic) binding between the posture information and the authenticated session to the NEA Server so the NEA Server knows the posture originated from the endpoint that authenticated. Such a strong binding between the posture's origin and the authenticating endpoint may be feasible so should be preferred by the NEA WG.
如果不兼容的活动MITM能够欺骗干净的端点放弃其姿态信息，并且MITM具有合法凭据，则在NEA服务器看来它可能具有兼容姿态，而实际上它没有。例如，不符合要求的MITM可以连接到NEA服务器并进行身份验证，当NEA服务器请求姿势信息时，MITM可以从清洁端点请求相同的姿势。如果清洁端点信任MITM执行重新评估，并且愿意共享请求的姿势，则MITM可以从清洁端点获得所需的姿势，并将其发送到NEA服务器。为了解决这种形式的MITM攻击，NEA协议需要在姿势信息和到NEA服务器的已验证会话之间提供强（加密）绑定，以便NEA服务器知道来自已验证端点的姿势。姿势的原点和认证端点之间的这种强绑定可能是可行的，因此NEA WG应首选。
Without message integrity protection, an attacker capable of intercepting a message might be capable of modifying its contents and causing an incorrect decision to be made. For example, the attacker might change the Posture Attributes to always reflect incorrect values and thus prevent a compliant system from joining the network. Unless the NEA Server could detect this change, the attacker could prevent admission to large numbers of clean systems. Conversely, the attacker could allow a malware infested machine to be admitted by changing the sent Posture Attributes to reflect compliant values, thus hiding the malware from the Posture Validator. The attacker could also infect compliant endpoints by sending malicious remediation instructions that, when performed, would introduce malware on the endpoint or deactivate security mechanisms.
如果没有消息完整性保护，能够拦截消息的攻击者可能会修改其内容并导致做出错误的决定。例如，攻击者可能更改姿态属性以始终反映不正确的值，从而阻止兼容系统加入网络。除非NEA服务器能够检测到此更改，否则攻击者可能会阻止进入大量干净的系统。相反，攻击者可以通过更改发送的姿态属性以反映兼容值来允许恶意软件感染的机器进入，从而对姿态验证器隐藏恶意软件。攻击者还可以通过发送恶意修复指令来感染兼容的端点，这些指令在执行时会在端点上引入恶意软件或停用安全机制。
In order to protect against such attacks, the PT includes a requirement for strong integrity protection (e.g., including a protected hash like a Hashed Message Authentication Code (HMAC) [HMAC] of the message) so any change to a message would be detected. PA includes a similar requirement to enable end-to-end integrity protection of the attributes, extending the protection all the way to the Posture Validator even if it is located on another system behind the NEA Server.
为了防止此类攻击，PT包括对强完整性保护的要求（例如，包括诸如消息的散列消息认证码（HMAC）[HMAC]之类的受保护散列），以便检测对消息的任何更改。PA包括一个类似的要求，以实现属性的端到端完整性保护，将保护一直扩展到姿态验证器，即使它位于NEA服务器后面的另一个系统上。
It is important that integrity protection schemes leverage fresh secret information (not known by the attacker) that is bound to the authenticated session such as an HMAC using a derived fresh secret associated with the session. Inclusion of freshness information allows the parties to protect against some forms of message replay attacks using secret information from prior sessions.
完整性保护方案必须利用绑定到已验证会话（如HMAC）的新机密信息（攻击者不知道），该信息使用与会话关联的派生新机密。包含新鲜度信息允许各方使用以前会话中的机密信息来防止某些形式的消息重播攻击。
An attacker might listen to the network, recording message dialogs or attributes from a compliant endpoint for later reuse to the same NEA Server or just to build an inventory of software running on other systems watching for known vulnerabilities. The NEA Server needs to be capable of detecting the replay of posture and/or the model must assure that the eavesdropper cannot obtain the information in the first place. For this reason, the PT protocol is required to provide confidentiality and replay prevention.
攻击者可能会监听网络，记录来自兼容端点的消息对话框或属性，以便稍后重新使用到同一NEA服务器，或者只是建立在其他系统上运行的软件清单，以查看已知漏洞。NEA服务器需要能够检测姿势的重放和/或模型必须确保窃听者首先无法获得信息。因此，PT协议需要提供机密性和重播预防。
The cryptographic protection from disclosure of the PT, PB, or PA messages prevents the passive listener from observing the exchanged messages and thus prevents theft of the information for future use. However, an active attacker might be able to replay the encrypted message if there is no strong link to the originating party or
防止PT、PB或PA消息泄露的加密保护可防止被动侦听器观察交换的消息，从而防止将来使用的信息被盗。但是，如果没有与发起方或发起方的强链接，活动攻击者可能能够重播加密消息
session. By linking the encrypted message dialog to the authentication event and leveraging per-transaction freshness and keying exchanges, this prevents a replay of the encrypted transaction.
一场通过将加密消息对话框链接到身份验证事件并利用每笔交易的新鲜度和密钥交换，这可以防止加密交易的重播。
This section doesn't claim to present an exhaustive list of attacks against the NEA reference model. Several types of attack will become easier to understand and analyze once the NEA WG has created specifications describing the specific selected technologies and protocols to be used within NEA. One such area is Denial of Service (DoS). At this point in time, it is not practical to try to define all of the potential exposures present within the NEA protocols, so such an analysis should be included in the Security Considerations sections of the selected NEA protocols.
本节并不要求提供针对NEA参考模型的攻击的详尽列表。一旦NEA工作组创建了描述NEA中使用的特定选定技术和协议的规范，几种类型的攻击将变得更容易理解和分析。其中一个领域是拒绝服务（DoS）。此时，试图定义NEA协议中存在的所有潜在风险是不切实际的，因此此类分析应包括在所选NEA协议的安全注意事项部分中。
However, it is important that the NEA Server be resilient to DoS attacks as an outage might affect large numbers of endpoints wishing to join or remain on the network. The NEA reference model expects that the PT protocol would have some amount of DoS resilience and that the PA and PB protocols would need to build upon that base with their own protections. To help narrow the window of attack by unauthenticated parties, it is envisioned that NEA Servers would employ PT protocols that enable an early mutual authentication of the requesting endpoint as one technique for filtering out attacks.
但是，NEA服务器必须能够抵御DoS攻击，因为停机可能会影响大量希望加入或留在网络上的端点。NEA参考模型预计PT协议将具有一定的DoS弹性，PA和PB协议需要在这一基础上建立自己的保护。为了帮助缩小未经认证方的攻击窗口，设想NEA服务器将采用PT协议，使请求端点的早期相互认证成为过滤攻击的一种技术。
Attacks occurring after the authentication would at least come from sources possessing valid credentials and could potentially be held accountable. Similarly, NEA protocols should offer strong replay protection to prevent DoS-based attacks based on replayed sessions and messages. Posture assessment should be strongly linked with the Posture Transport authentications that occurred to assure the posture came from the authenticated party. Cryptographic mechanisms and other potentially resource intensive operations should be used sparingly until the validity of the request can be established. This and other resource/protocol based attacks can be evaluated once the NEA technologies and their cryptographic use have been selected.
身份验证后发生的攻击至少来自拥有有效凭据的来源，并可能被追究责任。类似地，NEA协议应提供强大的重播保护，以防止基于重播会话和消息的DoS攻击。姿势评估应与姿势传输认证紧密联系，以确保姿势来自认证方。在建立请求的有效性之前，应谨慎使用加密机制和其他潜在的资源密集型操作。一旦选择了NEA技术及其加密用途，就可以评估这种和其他基于资源/协议的攻击。
While there are a number of beneficial uses of the NEA technology for organizations that own and operate networks offering services to similarly owned endpoints, these same technologies might enhance the potential for abuse and invasion of personal privacy if misused. This section will discuss a few of the potential privacy concerns raised by the deployment of this technology and offer some guidance to implementers.
虽然对于拥有和运营向类似拥有的端点提供服务的网络的组织来说，NEA技术有许多有益的用途，但如果被滥用，这些相同的技术可能会增加滥用和侵犯个人隐私的可能性。本节将讨论部署此技术引起的一些潜在隐私问题，并为实现者提供一些指导。
The NEA technology enables greater visibility into the configuration of an endpoint from the network. Such transparency enables the network to take into consideration the strength of the endpoint's security mechanisms when making access control decisions to network resources. However, this transparency could also be used to enforce restrictive policies to the detriment of the user by limiting their choice of software or prying into past or present uses of the endpoint.
NEA技术能够从网络中更好地了解端点的配置。这种透明性使网络在做出对网络资源的访问控制决策时能够考虑端点安全机制的强度。然而，这种透明性也可以用于强制执行限制性策略，通过限制用户对软件的选择或窥探端点的过去或现在的使用来损害用户的利益。
The scope of the NEA WG was limited to specifying protocols targeting the use cases where the endpoints and network are owned by the same party or the endpoint owner has established a clear expectation of disclosure/compliance with the network owner. This is a familiar model for governments, institutions, and a wide variety of enterprises that provide endpoints to their employees to perform their jobs. In many of these situations, the endpoint is purchased and owned by the enterprise and they often reserve the right to audit and possibly dictate the allowable uses of the device. The NEA technologies allow them to automate the inspection of the contents of an endpoint and this information may be linked to the access control mechanisms on the network to limit endpoint use should the endpoint not meet minimal compliance levels.
NEA工作组的范围仅限于指定针对同一方拥有端点和网络或端点所有者已明确预期披露/遵守网络所有者的用例的协议。对于政府、机构和各种各样的企业来说，这是一个熟悉的模型，它们为员工提供工作的端点。在许多情况下，端点是由企业购买和拥有的，他们通常保留审核的权利，并可能指定设备的允许使用。NEA技术允许他们自动检查端点的内容，这些信息可以链接到网络上的访问控制机制，以限制端点的使用，前提是端点不符合最低合规性水平。
In these environments, the level of personal privacy the employee enjoys may be significantly reduced subject to local laws and customs. However, in situations where the endpoint is owned by the user or where local laws protect the rights of the user even when using endpoints owned by another party, it is critical that the NEA implementation enable the user to control what endpoint information is shared with the network. Such controls imposed by the user might prevent or limit their ability to access certain networks or protected resources, but this must be a user choice.
在这些环境中，根据当地法律和习俗，员工享有的个人隐私水平可能会显著降低。然而，在端点归用户所有的情况下，或者即使在使用另一方拥有的端点时，当地法律也保护用户的权利的情况下，NEA实现使用户能够控制与网络共享的端点信息是至关重要的。用户施加的此类控制可能会阻止或限制其访问特定网络或受保护资源的能力，但这必须是用户的选择。
The NEA WG is not defining NEA Client policy content standards nor defining requirements on aspects of an implementation outside of the network protocols; however, the following guidance is provided to encourage privacy friendly implementations for broader use than just the enterprise-oriented setting described above.
NEA工作组未定义NEA客户端策略内容标准，也未定义网络协议以外实施方面的要求；但是，提供以下指南是为了鼓励隐私友好型实施，使其比上述面向企业的设置更广泛地使用。
NEA Client implementations are encouraged to offer an opt-in policy to users prior to sharing their endpoint's posture information. The opt-in mechanism should be on a per-user, per-NEA Server basis so each user can control which networks can access any posture information on their system. For those networks that are allowed to assess the endpoint, the user should be able to specify granular restrictions on what particular types and specific attributes Posture
鼓励NEA客户端实施在共享其端点姿态信息之前向用户提供选择加入策略。选择加入机制应基于每个用户、每个NEA服务器，以便每个用户可以控制哪些网络可以访问其系统上的任何姿势信息。对于允许评估端点的网络，用户应该能够指定特定类型和特定属性的粒度限制
Collectors are allowed to disclose. Posture Validator implementations are discouraged from having the default behavior of using wild carded requests for posture potentially leading to overexposure of information (see section 9.2). Instead Posture Validators, by default, should only request the specific attributes that are required to perform their assessment.
收集者可以披露。不鼓励姿态验证器实现使用通配符请求姿态的默认行为，这可能会导致信息的过度暴露（参见第9.2节）。相反，默认情况下，姿势验证器应该只请求执行评估所需的特定属性。
Requests for attributes that are not explicitly allowed (or specifically disallowed) to be shared should result in a user notification and/or log record so the user can assess whether the service is doing something undesirable or whether the user is willing to share this additional information in order to gain access. Some products might consider policy-driven support for prompting the user for authorization with a specific description of the posture information being requested prior to sending it to the NEA Server.
对未明确允许（或明确禁止）共享的属性的请求应导致用户通知和/或日志记录，以便用户可以评估服务是否正在做不希望做的事情，或者用户是否愿意共享此附加信息以获得访问权。有些产品可能会考虑策略驱动的支持，以便在将其发送到NEA服务器之前，对请求的姿态信息进行具体描述来提示用户进行授权。
It is envisioned that the owner of the endpoint is able to specify disclosure policies that may override or influence the user's policies on the attributes visible to the network. If the owner disclosure policy allows for broader posture availability than the user policy, the implementation should provide a feedback mechanism to the user so they understand the situation and can choose whether to use the endpoint in those circumstances.
可以设想，端点的所有者能够指定公开策略，这些策略可以覆盖或影响用户对网络可见属性的策略。如果所有者披露策略允许比用户策略更广泛的姿态可用性，则实现应向用户提供反馈机制，以便用户了解情况并可以选择是否在这些情况下使用端点。
In such a system, it is important that the user's policy authoring interface is easy to understand and clearly articulates the current disclosure policy of the system including any influences from the owner policy. Users should be able to understand what posture is available to the network and the general impact of this information being known. In order to minimize the list of restrictions enumerated, use of a conservative default disclosure policy such as "that which is not explicitly authorized for disclosure is not allowed" might make sense to avoid unintentional leakage of information.
在这样的系统中，用户的策略编写界面必须易于理解，并清楚地阐明系统的当前披露策略，包括所有者策略的任何影响。用户应该能够了解网络上可用的姿势以及已知信息的一般影响。为了尽量减少列举的限制清单，使用保守的默认披露政策，如“不允许未明确授权披露的内容”可能有助于避免无意中泄露信息。
NEA Server implementations should provide newly subscribing endpoints with a disclosure statement that clearly states:
NEA服务器实施应为新订阅的端点提供一份披露声明，明确说明：
o What information is required
o 需要什么信息
o How this information will be used and protected
o 如何使用和保护这些信息
o What local privacy policies are applicable
o 适用哪些本地隐私政策
This information will empower subscribing users to decide whether the disclosure of this information is acceptable considering local laws and customs.
该信息将授权订阅用户根据当地法律和习俗决定是否可以接受披露该信息。
One important issue in the design of the NEA reference model and protocols is enabling endpoints to disclose minimal information required to establish compliance with network policies. There are several models that could be considered as to how the disclosed attribute set is established. Each model has privacy related benefits and issues that should be considered by product developers. This section summarizes three potential models for how attribute disclosure might be provided within NEA products and some privacy implications potentially associated with each model.
NEA参考模型和协议设计中的一个重要问题是使端点能够披露建立网络策略合规性所需的最少信息。关于如何建立公开的属性集，可以考虑几个模型。每个模型都有与隐私相关的好处和问题，产品开发人员应该考虑这些好处和问题。本节总结了NEA产品中如何提供属性披露的三种潜在模型，以及可能与每种模型相关的一些隐私影响。
The first model is easy to implement and deploy but has privacy and potentially latency and scalability implications. This approach effectively defaults the local policy to send all known NEA Posture Attributes when an assessment occurs. While this might simplify deployment, it exposes a lot of information that is potentially not relevant to the security assessment of the system and may introduce privacy issues. For example, is it really important that the enterprise know whether Firefox is being used on a system instead of other browsers during the security posture assessment?
第一个模型易于实现和部署，但具有隐私性、潜在的延迟和可伸缩性。这种方法有效地默认了本地策略，即在进行评估时发送所有已知的NEA姿态属性。虽然这可能会简化部署，但它会暴露大量与系统安全评估可能不相关的信息，并可能引入隐私问题。例如，在安全态势评估期间，企业是否真的需要知道Firefox是否在系统上而不是在其他浏览器上使用？
The second model involves an out-of-band provisioning of the disclosure policy to all endpoints. This model may involve the enterprise establishing policy that a particular list of attributes must be provided when a NEA exchange occurs. Endpoint privacy policy may filter this attribute list, but such changes could cause the endpoint not to be given network or resource access. This model simplifies the network exchange as the endpoint always sends the filtered list of attributes when challenged by a particular network. However, this approach requires an out-of-band management protocol to establish and manage the NEA disclosure policies of all systems.
第二个模型涉及向所有端点提供公开策略的带外供应。该模型可能涉及企业制定策略，即在发生NEA交换时必须提供特定的属性列表。端点隐私策略可能会筛选此属性列表，但此类更改可能会导致端点无法访问网络或资源。该模型简化了网络交换，因为当受到特定网络的质询时，端点总是发送过滤后的属性列表。然而，这种方法需要一个带外管理协议来建立和管理所有系统的NEA披露政策。
The third model avoids the need for pre-provisioning of a disclosure policy by allowing the NEA Server to specifically request what attributes are required. This is somewhat analogous to the policy being provisioned during the NEA exchanges so is much easier to manage. This model allows for the NEA Server to iteratively ask for attributes based on the values of prior attributes. Note, even in this model the NEA protocols are not expected to be a general purpose query language, but rather allow the NEA Server to request specific attributes as only the defined attributes are possible to request. For example, an enterprise might ask about the OS version in the initial message dialog and after learning the system is running Linux ask for a different set of attributes specific to Linux than it would if the endpoint was a Windows system. It is envisioned that this
第三种模式允许NEA服务器专门请求所需的属性，从而避免了预先提供披露策略的需要。这在某种程度上类似于NEA交换期间提供的政策，因此更易于管理。该模型允许NEA服务器根据先前属性的值迭代请求属性。注意，即使在该模型中，NEA协议也不应是通用查询语言，而是允许NEA服务器请求特定属性，因为只有定义的属性才能请求。例如，企业可能会在初始消息对话框中询问操作系统版本，并且在了解到系统正在运行Linux后，会询问与端点是Windows系统时不同的一组特定于Linux的属性。可以预见这一点
approach might minimize the set of attributes sent over the network if the assessment is of a complex system (such as trying to understand what patches are missing from an OS).
如果评估是针对一个复杂系统（例如试图了解操作系统缺少哪些补丁），这种方法可能会最小化通过网络发送的属性集。
In each model, the user could create a set of per-network privacy filter policies enforced by the NEA Client to prevent the disclosure of attributes felt to be personal in nature or not relevant to a particular network. Such filters would protect the privacy of the user but might result in the user not being allowed access to the desired asset (or network) or being provided limited access.
在每种模型中，用户可以创建一组由NEA客户端强制实施的每网络隐私过滤策略，以防止披露本质上属于个人或与特定网络无关的属性。此类过滤器将保护用户的隐私，但可能导致不允许用户访问所需的资产（或网络）或限制用户访问。
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF8]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[802.1X] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2001, June 2001.
[802.1X]IEEE局域网和城域网标准：基于端口的网络访问控制，IEEE标准802.1X-2001，2001年6月。
[CNAC] Cisco, Cisco's Network Admission Control Main Web Site,
http://www.cisco.com/go/nac
[CNAC] Cisco, Cisco's Network Admission Control Main Web Site,
http://www.cisco.com/go/nac
[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[EAP]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，Ed.，“可扩展认证协议（EAP）”，RFC 3748，2004年6月。
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC 2104，1997年2月。
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[IPSEC]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[NAP] Microsoft, Network Access Protection Main Web Site,
http://www.microsoft.com/nap
[NAP] Microsoft, Network Access Protection Main Web Site,
http://www.microsoft.com/nap
[RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RADIUS]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[TLS]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[TCG] Trusted Computing Group, Main TCG Web Site,
http://www.trustedcomputinggroup.org/
[TCG] Trusted Computing Group, Main TCG Web Site,
http://www.trustedcomputinggroup.org/
[TNC] Trusted Computing Group, Trusted Network Connect Main Web
Site, https://www.trustedcomputinggroup.org/groups/network/
[TNC] Trusted Computing Group, Trusted Network Connect Main Web
Site, https://www.trustedcomputinggroup.org/groups/network/
The authors of this document would like to acknowledge the NEA Working Group members who have contributed to previous requirements and problem statement documents that influenced the direction of this specification: Kevin Amorin, Parvez Anandam, Diana Arroyo, Uri Blumenthal, Alan DeKok, Lauren Giroux, Steve Hanna, Thomas Hardjono, Tim Polk, Ravi Sahita, Joe Salowey, Chris Salter, Mauricio Sanchez, Yaron Sheffer, Jeff Six, Susan Thompson, Gary Tomlinson, John Vollbrecht, Nancy Winget, Han Yin, and Hao Zhou.
本文件的作者要感谢对影响本规范方向的先前要求和问题陈述文件做出贡献的NEA工作组成员：凯文·阿莫林、帕维斯·阿南达姆、黛安娜·阿罗约、乌里·布卢门塔尔、艾伦·德科克、劳伦·吉鲁、史蒂夫·汉纳、托马斯·哈德乔诺、蒂姆·波尔克、，Ravi Sahita、Joe Salowey、Chris Salter、Mauricio Sanchez、Yaron Sheffer、Jeff Six、Susan Thompson、Gary Tomlinson、John Vollbrecht、Nancy Winget、Han Yin和Hao Zhou。
Authors' Addresses
作者地址
Paul Sangster Symantec Corporation 6825 Citrine Dr Carlsbad, CA 92009 USA Phone: +1 760 438-5656 EMail: Paul_Sangster@symantec.com
Paul Sangster Symantec Corporation 6825 Citrine Dr Carlsbad，CA 92009美国电话：+1 760 438-5656电子邮件：Paul_Sangster@symantec.com
Hormuzd Khosravi Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA Phone: +1 503 264 0334 EMail: hormuzd.m.khosravi@intel.com
Hormuzd Khosravi Intel 2111 NE 25 Avenue Hillsboro，或97124美国电话：+1 503 264 0334电子邮件：Hormuzd.m。khosravi@intel.com
Mahalingam Mani Avaya Inc. 1033 McCarthy Blvd. Milpitas, CA 95035 USA Phone: +1 408 321-4840 EMail: mmani@avaya.com
Mahalingam Mani Avaya Inc.麦卡锡大道1033号。加利福尼亚州米尔皮塔斯95035美国电话：+1408 321-4840电子邮件：mmani@avaya.com
Kaushik Narayan Cisco Systems Inc. 10 West Tasman Drive San Jose, CA 95134 Phone: +1 408 526-8168 EMail: kaushik@cisco.com
Kaushik Narayan Cisco Systems Inc.加利福尼亚州圣何塞西塔斯曼大道10号95134电话：+1 408 526-8168电子邮件：kaushik@cisco.com
Joseph Tardo Nevis Networks 295 N. Bernardo Ave., Suite 100 Mountain View, CA 94043 USA EMail: joseph.tardo@nevisnetworks.com
Joseph Tardo Nevis Networks美国加利福尼亚州山景城Bernardo大道北295号100室邮编94043电子邮件：Joseph。tardo@nevisnetworks.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.