RFC 5209
Network Endpoint Assessment (NEA): Overview and Requirements
Part 1 of 12 ✨
RFC 5209: Network Endpoint Assessment (NEA): Overview and Requirements 💖
Okay bestie, so this is RFC 5209, from the Network Working Group, published in June 2008 🌸. It's Informational, which means it's here to give context and not to be a standard. The authors are P. Sangster (Symantec), H. Khosravi (Intel), M. Mani (Avaya), K. Narayan (Cisco Systems), and J. Tardo (Nevis Networks) 🫶. It doesn't obsolete or update any other RFCs, so it's a solo main character 👑.
Status of This Memo 📜
This memo is just information for the Internet community 🎀. It does not specify an Internet standard of any kind, and distribution of this memo is unlimited 🌈.
Abstract 🦋
Okay so this document is where the problem statement, scope, and protocol requirements get defined for the parts of the NEA (Network Endpoint Assessment) reference model 💅. NEA gives network owners, like an enterprise offering remote access, a way to check the posture of a system 🔍. That check can happen when a system is asking for network access, and/or any time after it's already connected ⏰. The posture info that gets learned can then be used for all kinds of compliance decisions 📋. It's especially useful for spotting systems that are missing or have outdated protection, like anti-virus and host-based firewall software 🛡️. To give the requirements some context, the document introduces a reference model and some terminology 🧚.
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
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 ...............................................511. Introduction ✨
Okay so endpoints that are connected to a network can be exposed to a wild variety of threats 😭. Some protection against those threats comes from making sure endpoints follow security policies 🔒. That's why NEA exists: it assesses endpoints to see whether they comply with security policies, so corrective measures can be applied before the endpoint gets exposed to those threats 💪. Say a system is out of compliance because it's missing defenses like host-based firewalls, anti-virus software, or critical security patches. The NEA protocols give a way to detect that and to indicate the remediation actions that should be taken 🩹. Also, a endpoint that counts as compliant can still be vulnerable to threats that exist on the network 🙈.
NEA usually involves special client software running on the endpoint that's asking for access 🧑💻. That software watches and reports on how the system is configured, back to the network infrastructure 📡. The infrastructure has matching validation software that can compare the endpoint's configuration info with the network's compliance policies. It then passes the result along to the authorization entities that decide about network and application access 👑. Some endpoints might not be able to run the NEA Client software (a printer, for example), or they might not want to share info about their configuration 🖨️. That situation is outside the scope of NEA and is handled by local policies 🌸.
The result of an endpoint assessment may influence an access decision, and that decision gets provisioned to the enforcement mechanisms on the network and/or the endpoint requesting access 🚪. The NEA Working Group knows there may be a link between an assessment and enforcing the resulting access decision 🤝. However, the mechanisms and protocols for enforcement are not in scope for this specification 🚫.
Similar architectures to NEA have been around in the industry for a while and are in shipping products, but they don't offer adequate interoperability 😤. A few examples are Trusted Computing Group's Trusted Network Connect [TNC], Microsoft's Network Access Protection [NAP], and Cisco's Cisco Network Admission Control [CNAC] 🏢. These technologies check the software and/or hardware configuration of endpoint devices, either to monitor compliance with an organization's policy or to enforce it 📋.
The NEA Working Group is building standard protocols that can be used to share compliance information between a NEA Client and a NEA Server 🎀. This document sets up the context for NEA, covering terminology, applicability, problem statement, reference model, and use cases 🧠. After that, it identifies requirements for the protocols used to communicate between a NEA Client and a NEA Server 💅. Finally, the document talks through some potential security and privacy considerations for using NEA 🔐. Most of this specification is informative text that describes the context of NEA 🦋.
1.1. Requirements Language 💅
Okay so every capitalized word in a sentence or phrase carries a specific meaning during the NEA WG's protocol selection process 📝. Here's how they break down:
- 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 🌈
Lowercase "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" just mean what they normally mean, and they aren't subject to these definitions 🫶.
2. Terminology ✨
okay so this section is basically the glossary bestie 🎀 these words get used in other contexts with different meanings, so this section tells you what each one means for NEA WG stuff specifically. no mix-ups allowed 💅
Assessment - the process of collecting posture for a set of capabilities on the endpoint (e.g., host-based firewall) so the right validators can check that posture against compliance policy 🔍
Assertion Attributes - attributes with reusable info about how a previous assessment of the endpoint went 🧾 this can speed up later assessments by skipping a full posture reassessment. like, this kind of attribute might get issued to one specific endpoint, dated and signed by the NEA Server, so that endpoint can reuse it for a set time period to claim it's compliant with a set of policies. the NEA Server might accept it instead of getting posture info 🫶
Attribute - a data element (with any needed meta-data) describing an observed, expected, or operational status of an endpoint feature (e.g., anti-virus software is currently in use) 🦋 attributes get swapped as part of the NEA protocols (see section 5.2). NEA sees a bunch of usage scenarios where an attribute in a particular type of message could mean:
- previously assessed status (Assertion Attributes),
- observed configuration or property (Posture Attributes),
- request for configuration or property information (Request Attributes),
- assessment decision (Result Attributes), or
- repair instructions (Remediation Attributes).
the NEA WG will standardize a subset of the attribute namespace called standard attributes 📚 anything not standardized is called vendor-specific in this spec 🌸
Dialog - a sequence of request/response messages that get exchanged 💬
Endpoint - any computing device that can connect to a network 💻 these usually have a link layer address before joining the network and maybe an IP address once they're on it. this includes laptops, desktops, servers, cell phones, or any device that might have an IP address 📱 main character energy for every device 🧚
Message - a self-contained unit of communication between the NEA Client and Server 📩 for example, a posture attribute message might carry a set of attributes describing how the anti-virus software on an endpoint is configured 🛡️
Owner - the role of an entity that's the legal, rightful possessor of an asset (e.g., endpoint) 👑 the owner is entitled to keep control over the policies enforced on the device, even if the asset isn't in the owner's possession. the owner may allow user override or augmentation of control policies, or may choose not to assert any policies limiting use of the asset 🫶
Posture - the configuration and/or status of hardware or software on an endpoint, as it relates 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 it wants from the NEA Client 🙋♀️ for example, a Request Attribute might be an attribute in a request message from the NEA Server asking for the version info of the endpoint's operating system ✨
Remediation Attributes - attributes containing the remediation instructions for how to bring an endpoint into compliance with one or more policies 🔧 the NEA WG won't define standard remediation attributes, but this spec does describe where they're used within the reference model and protocols 🗺️
Result Attributes - attributes describing whether the endpoint is in compliance with NEA policy 🏁 the NEA Server usually creates the Result Attribute at the end of the assessment to say whether the endpoint was considered compliant or not. more than one of these can be used, which allows more granular feature-level decisions to be communicated alongside an overall, global assessment decision 💖
Session - a stateful connection that can carry multiple message exchanges associated with (an) assessment(s) of a particular endpoint 🧸 this document defines session at a conceptual level only. it doesn't describe the properties of the session or specify requirements for the NEA protocols to manage these sessions 🤷♀️
User - the role of a person who is using the services of an endpoint 🙋 the user may not own the endpoint, so they might need to operate within the acceptable use constraints set by the endpoint's owner. for example, an enterprise employee might be a user of a computer the enterprise (owner) provides for business purposes 💼
3. Applicability 🌷
this section talks about the scope of the technologies being standardized, and the network environments where NEA tech might be applicable 🗺️
3.1. Scope
the NEA Working Group's top priority is developing standard protocols at the higher layers of the reference model (see section 5): the Posture Attribute protocol (PA) and the Posture Broker protocol (PB) 🎯 PA and PB are 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 might be defined in other WGs, because the requirements might not be specific to NEA 🫶 when used with a standard PT protocol (e.g., Extensible Authentication Protocol (EAP), Transport Layer Security (TLS) [TLS]), PA and PB will allow interoperability between a NEA Client from one vendor and a NEA Server from another 🤝 this spec won't focus on the other interfaces between the functional components of the NEA reference model, or on requirements for their internals. any discussion of these aspects is included just to give context for understanding the model and the resulting requirements 💅
some tangent areas that aren't shown in the reference model are also out of scope for the NEA WG, and therefore this spec, including:
- Standardizing the protocols and mechanisms for enforcing restricted network access,
- Developing standard protocols for remediation of non-compliant endpoints,
- Specifying protocols used to communicate with remote portions of the NEA Client or Server (e.g., remote collectors or validators of posture),
- 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),
- Defining the set of events or situations that might trigger a NEA Client or NEA Server to request an assessment,
- Detecting or handling lying endpoints (see section 8.1.1 for more information).
3.2. Applicability of Environments
okay this part is so important 🥺 because NEA is based on NEA-oriented software being on the endpoint and in the network infrastructure, and because of the nature of the info being exposed, NEA might not apply in a lot of situations on the Internet 🌐 so this section covers some scenarios where NEA is most likely to apply, and some where it may not. but the use of NEA in a deployment isn't limited to just these scenarios 🙌 whether to use NEA is up to the deployer (e.g., network provider), based on the expected relationship they have with the owners and users of potential endpoints 🤝
NEA tech is mostly focused on scenarios where the owner of the endpoint is the same as the owner of the network 🏢 this is a super common model for enterprises that give equipment to employees to do their jobs 💼 these employees are likely bound by an employment contract that spells out how much visibility the employer expects to have into the employee's use of company assets, and possibly their activities during work hours 📋 that contract might set the expectation that the endpoint needs to conform to the enterprise's policies 🫶
some other environments might be in a similar situation and find NEA tech beneficial 💜 for example, environments where the endpoint is owned by a party (possibly even the user) who has clearly said they want to conform to the policies set by a network or service provider, in exchange for being able to access its resources ✨ an example is an independent contractor with a personal laptop, working for a company that imposes NEA assessment policies on its employees, who might want a similar level of access and is willing to conform to the company's policies 🎀 NEA tech may be applicable to this situation 🦋
on the flip side, NEA is not expected to be applicable in environments where the endpoint is owned by a user who hasn't agreed to conform to a network provider's policies 🙅♀️ an example is when that same contractor visits a public area like the local coffee shop that offers Internet access ☕ the coffee shop wouldn't be expected to be able to use NEA tech to assess the posture of the contractor's laptop 😭 because NEA is potentially invasive, that kind of assessment could amount to an invasion of privacy for the contractor 🙈
it's harder to tell whether NEA is applicable in other environments, so the NEA WG will consider those out of scope for consideration and specification 🚫 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 📜 that expectation likely includes a willingness to disclose the appropriate information the network needs to perform compliance checks 🔍 iykyk the vibe is consent first 💖
4. Problem Statement ✨
okay so NEA tech can be used for a bunch of different things, bestie 💖 this section covers some of the big situations where NEA is lowkey a lifesaver 🫶
One use is checking that an endpoint follows an organization's security policy when it connects to the network 🔥 Orgs often want endpoints running an IT-specified Operating System (OS) configuration with certain security apps turned on, e.g., anti-virus software, host intrusion detection/prevention systems, personal firewalls, and patch management software. An endpoint that's not compliant with IT policy might be vulnerable to a bunch of known threats that could be lurking on the network 😭
Without NEA tech, making sure endpoints follow corporate policy is a whole time-consuming, difficult mess 💀 Not every endpoint is managed by a corp's IT org, like lab assets and contractor machines. Even managed ones might not get updates in a timely way because they aren't permanently attached to the corporate network, like laptops. With NEA, the network can assess an endpoint as soon as it requests access, or at any time after it joins. That gives the corp a chance to check compliance of all NEA-capable endpoints in a timely way and help with remediation, potentially while they're quarantined when needed 🦋
NEA can provide posture assessment for a range of ways to connect 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 🌸
Endpoints that aren't NEA-capable, or that choose not to share enough posture to be evaluated for compliance, may be subject to different access policies 🙈 The network administrator decides how to handle non-compliant or non-participating endpoints, 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 NEA results to restrict or deny access to an endpoint, while letting vulnerabilities get addressed before the endpoint is exposed to attack. How NEA assessment results get communicated and represented to network access technologies on the network is out of scope for this document 💅
Reassessment is a second important use, and it's giving main character energy 👑 It lets the network run additional assessments on endpoints that were already considered compliant. This might become necessary because network compliance policies and/or endpoint posture can change over time. A system that was assessed as compliant when it joined might stop being compliant after changes happen. For example, reassessment might be necessary if a user disables a security protection required by policy (e.g., a host-based firewall), or when a firewall becomes non-compliant after a firewall patch is issued and network policy is changed to require that patch 🔥
A third use of NEA tech may be to verify or supplement organization asset information stored in inventory databases 🧚
NEA technology can also check and report compliance for endpoints when they try to access certain mission critical applications within an enterprise, using service (application) triggered assessment 💜
5. Reference Model 🦋
okay this section describes the reference model for Network Endpoint Assessment 🎀 The model is there to set up context for the requirements discussion, and it may not directly map to any particular product or deployment architecture. It shows the major functionality of the NEA Client and Server and how they relate, plus the protocols they use to talk to each other at different levels (e.g., PA is carried by the PB protocol) 🧠
While the diagram shows 3 layered protocols, PA is likely a thin message wrapper around a set of attributes, and it gets 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 🙌
+-------------+ +--------------+
| 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
Figure 1: NEA Reference ModelThe NEA reference model doesn't include mechanisms for discovering NEA Clients and NEA Servers 🔍 It's expected that NEA Clients and NEA Servers are configured with information that lets them reach each other. The specific methods of referencing that configuration and setting up the communication channel are out of scope for the NEA reference model, and they should be covered in the specs of candidate protocols like the Posture Transport (PT) protocol 💅
5.1. NEA Client and Server 💖
5.1.1. NEA Client 🎀
The NEA Client lives on an endpoint device and is made up of the following functionality:
- Posture Collector(s)
- Posture Broker Client
- Posture Transport Client(s)
The NEA Client is responsible for responding to requests for attributes that describe the configuration of the local operating domain of the client, and for handling 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 but are outside its domain of execution (e.g., in other virtual machine domains) 🙈
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 🧚
Endpoints that lack NEA Client software (which is out of NEA scope), or that choose not to provide the attributes required by the NEA Server, could be considered non-compliant 😬 The NEA model includes capabilities that let the endpoint update its contents so it can become compliant 🫶
5.1.1.1. Posture Collector 🔥
The Posture Collector is responsible for responding to requests for posture information in Request Attributes from the NEA Server 🙌 It's also responsible for handling assessment decisions in Result Attributes and remediation instructions in Remediation Attributes. A single NEA Client can have several Posture Collectors, each capable of collecting standard and/or vendor-specific Posture Attributes for particular features of the endpoint. Typical 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 a host-based Intrusion Detection System (IDS) or firewall 🛡️
Each Posture Collector will be associated with one or more identifiers that let it 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 wants to receive (e.g., message type for subscription) 🦋
The NEA model allocates the following responsibilities to the Posture Collector 💅
- Consulting with local privacy and security policies that may restrict what information is allowed to be disclosed to a given NEA Server.
- Receiving Request Attributes from a Posture Validator and performing the local processing required to respond appropriately. This may include:
- 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.
- 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.
- Monitoring the posture of (a) particular features(s) on the endpoint for posture changes that require notification to the Posture Broker Client.
- Providing cryptographic verification of the attributes received from the Validator and offering cryptographic protection to the attributes returned.
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 ✨
5.1.1.2. Posture Broker Client 🎀
okay bestie, the Posture Broker Client is both a PA message multiplexer AND a de-multiplexer 💅 It's 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 the posture information request to be pre-provisioned on the NEA Client, which improves performance by letting the NEA Client report posture without waiting for a request for particular attributes from the NEA Server ✨
The Posture Broker Client also multiplexes the responses from the Posture Collector(s) and sends them back to the NEA Server 🦋 It builds one or more PB messages using the PA message(s) it gets from the Posture Collector(s) involved in the assessment. The quantity and ordering of Posture Collector responses (PA message(s)) packed into the PB response message(s) can be decided by the Posture Broker Client based on lots of factors, including policy or the characteristics of the underlying network transport (e.g., MTU). A particular NEA Client will have one Posture Broker Client, period 💖
It also handles the global assessment decision from the Posture Broker Server, and it may interact with the user to communicate that decision and help with any necessary remediation steps 🫶
The NEA model gives the Posture Broker Client these responsibilities:
- Maintaining a registry of known Posture Collectors and allowing Posture Collectors to dynamically register and deregister 📋
- Multiplexing and de-multiplexing attribute messages between the NEA Server and the relevant Posture Collectors 🔀
- Handling posture change notifications from Posture Collectors and triggering reassessment 🔔
- Providing user notification about the global assessment decision and other user messages sent by the NEA Server 💌
5.1.1.3. Posture Transport Client 🚀
The Posture Transport Client is responsible for setting up 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.
The NEA model gives the Posture Transport Client these responsibilities:
- Initiating and maintaining the communication channel to the NEA Server. The Posture Transport Client hides the details of the underlying carrier, which could be a Layer 2 or Layer 3 protocol 🙈
- Providing cryptographic protection for the message dialog between the NEA Client and NEA Server 🔐
5.1.2. NEA Server 🌈
The NEA Server is typically made up of the following NEA functionality:
- Posture Validator(s)
- Posture Broker Server
- Posture Transport Server(s)
The Posture Validators might live on a separate server from the Posture Broker Server, which means the Posture Broker Server has to deal with both local and remote Posture Validators 🧚
5.1.2.1. Posture Validator 👑
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 let it be specified as the destination in a PA message. The Posture Broker Server uses this identifier to route messages to this Validator. The 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 wants to receive (e.g., message type for subscription) 🗝️
Posture Validators can be co-located on the NEA Server or hosted on separate servers. A particular NEA Server is likely to need to handle multiple Posture Validators 🍓
The NEA model gives the Posture Validator these responsibilities:
- Requesting attributes from a Posture Collector. The request may include:
- Request Attributes that tell the Posture Collector to fetch and provide Posture Attributes for particular functionality on the endpoint 🎯
- Receiving attributes from the Posture Collector. The response from the Posture Collector may include:
- Posture Attributes collected for the requested functionality.
- Assertion Attributes that indicate the compliance result from a prior assessment 📜
- Assessing the posture of endpoint features based on the attributes received from the Collector 🧐
- Communicating the posture assessment result to the Posture Broker Server 📨
- Communicating the posture assessment results to the Posture Collector. This attribute message may include:
- Result Attributes that communicate the posture assessment result.
- Remediation Attributes that communicate the remediation instructions to the Posture Collector 🛠️
- Monitoring out-of-band updates that trigger reassessment and require notifications to be sent to the Posture Broker Server 👀
- Providing cryptographic protection for attributes sent to the Posture Collector, and offering cryptographic verification of the attributes received from the Posture Collector 🔐
The list above 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 everything a Posture Validator may do 🦋
5.1.2.2. Posture Broker Server 🌷
The Posture Broker Server acts as a multiplexer and a de-multiplexer for attribute messages. It parses the PB messages received from the NEA Client and de-multiplexes them into PA messages, which it passes to the associated Posture Validators 🔍 It 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 the global assessment decision multiplexed into the PB response message(s) can be decided by the Posture Broker Server based on lots of factors, including policy or the characteristics of the underlying network transport (e.g., 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. That 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 👑
The NEA model gives the Posture Broker Server these responsibilities:
- Maintaining a registry of Posture Validators and allowing Posture Validators to register and deregister 📋
- Multiplexing and de-multiplexing posture messages from and to the relevant Posture Validators 🔀
- 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 🏆
5.1.2.3. Posture Transport Server 🚚
The Posture Transport Server is responsible for setting up 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 it may need local configuration describing how to reach the NEA Clients.
The NEA model gives the Posture Transport Server these responsibilities:
- Initiating and maintaining a communication channel with, potentially, several NEA Clients 🤝
- Providing cryptographic protection for the message dialog between the NEA Client and NEA Server 🔐
5.2. Protocols 💜
The NEA reference model includes three layered protocols (PA, PB, and PT) that allow the exchange of attributes across the network. These protocols are meant to be used together to fulfill a particular role in the model, but 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) 🛡️
5.2.1. Posture Attribute Protocol (PA) 🌈
PA is a protocol that carries one or more attributes between Posture Collectors and their associated Posture Validator. It's a message-oriented, lightweight wrapper around a set of attributes being exchanged, and this wrapper may indicate the purpose of the attributes within the message 🎁 Some of the message types 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 required encoding and cryptographic protection for the Posture Attributes 🔥
5.2.2. Posture Broker Protocol (PB) 🍭
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 that allows 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) 🌍
5.2.3. Posture Transport Protocol (PT) 🚚
okay so PT is the transport protocol between the NEA Client and the NEA Server, and its whole job is carrying the messages that the PB protocol generates. The PT protocol(s) transport(s) PB messages during the network connection request or after network connectivity has been established. 💌
In scenarios where an initial assessment needs to happen 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 before the assessment, based on properties of the underlying network protocol. Using this info, NEA policy could dictate what aspects of the endpoint go into 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 skip the limiting altogether by configuring their network access technology to temporarily grant restricted IP connectivity before the assessment, then 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:
- Limited maximum transmission unit (MTU) size and ability to negotiate larger MTUs,
- Inability to perform multiple roundtrips,
- Lack of support for piggybacking attributes for other protocols,
- Low bandwidth or high latency limitations precluding exchanges of large amounts of data,
- Inability of servers to initiate messages except during the network connection phase.
The PT protocol selection process needs to consider how a particular PT and its set of underlying protocols will affect 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. 🙈
The PT protocol provides reliable message delivery, mutual authentication, and cryptographic protection for the PB messages as specified by local policy. 🔐
5.3. Attributes 💅
okay the PA protocol handles the exchange of attributes between a Posture Collector and a Posture Validator. The PB protocol may also carry the global assessment decision attributes from the Posture Broker Server. Attributes are basically the 'nouns' of the posture assessment (the reserved word, lol 🤭). The NEA Server is only able to ask for information that has a corresponding attribute, so attributes bound 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 those get used for maximum interoperability. Posture Collectors may still support additional vendor-specific attributes when necessary. 🎀
Depending on the deployment scenario, the purpose of the attributes exchanged may be different (e.g., posture information vs. asserted compliance). This section looks at who originates each classification of attributes and the situation that leads to using each one in a PA message. These classifications are not meant to dictate how the NEA WG will specify the attributes when it defines the attribute namespace or schema. 📚
5.3.1. Attributes Normally Sent by NEA Client: 📤
- 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. 🧱
- 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. 🍪
5.3.2. Attributes Normally Sent by NEA Server: 📥
- Request Attributes - Attributes that define the specific posture information the NEA Server wants. 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. 📝
- 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, all the way through to just the global assessment decision. 🏁
- 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. 🛠️
- 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. 🫶
6. Use Cases 🌈
this section talks through several of the NEA use cases, mainly to describe and collectively bound the NEA problem space. The use cases give context and the general reasoning behind the defined requirements. To make each use case easier to get and see how it maps to the reference model, each one comes with a simple example plus a discussion of how that example relates to the NEA protocols. It should be emphasized that the examples are not meant to be the only way to address a use case. They're just there so you can picture how the flows might happen and how they affect the NEA protocols. 👀
we broadly sort the use cases into two categories, each with its own set of trigger events:
- 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. 🌱
- 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. ⏰
6.1. Initial Assessment 🆕
an initial assessment happens when a NEA Client or Server event occurs that causes the posture of the endpoint to be evaluated 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 its posture evaluated again. 🙌
6.1.1. Triggered by Network Connection or Service Request 🚪
this use case is about assessments performed when an endpoint tries to join a network or request use of a service that requires a posture evaluation. It's especially interesting because it lets the NEA Server evaluate the posture of an endpoint before allowing it access to the network or service. 🔍
this approach could help detect endpoints with known vulnerabilities and get them repaired before they're admitted to the network and potentially exposed to threats on it. 🛡️
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. 💼
6.1.1.1. Example 🎬
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. 💻✨
6.1.1.2. Possible Flows and Protocol Usage 💅
okay so here's the full play-by-play of how messages move through the NEA reference model for this example 🎀 it's a lot, but the story arc is iconic ✨
- The IT employee's desktop computer connects to the network through an access gateway in the wired enterprise network. 🖥️
- The Posture Broker Server on the NEA Server is instructed to assess the endpoint joining the wired network. 🧚
- 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. 📋
- 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, which uses the PT protocol to send the PB message to the NEA Client on the desktop computer. 🦋
- The Posture Transport Client receives the message from the NEA Server and passes it to the Posture Broker Client for message delivery. 📬
- 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. 🔍
- 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. 🔒
- 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. 💜
- The Posture Transport Server provides the PB message to the Posture Broker Server, which de-multiplexes the message and sends the appropriate attributes to the corresponding Posture Validator. 🌸
- Each Posture Validator compares the values of the attributes it receives with the expected values defined in its policy. ⭐
- 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 the non-compliance result.
- 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. 📦
- 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 for 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. 🩹
- Upon completion of the remediation, steps 1-10 above are repeated (triggered by the NEA Client repeating its request to join the network). 🔁
- 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. 🎉
- The Posture Broker Client receives the compliant result, and the IT employee's desktop is now on the network. iconic, honestly 🫶
6.1.1.3. Impact on Requirements
okay, here are the different aspects of this use case that could need to be factored into the requirements 👀
- Posture assessment before endpoint allowed on network
- Endpoint sends attributes containing posture information
- NEA Server sends remediation instructions
- NEA Client causes a reassessment after remediation
6.1.2. Triggered by Endpoint
this one is all about the endpoint taking the wheel 🦋 An endpoint (possibly at the request of a user) may wish to trigger an assessment of its posture, to find out whether its security protective mechanisms are running and up to date. It's giving self-care for your laptop, bestie 🧴💖
6.1.2.1. Example
okay this story is so relatable 🎓 A student goes to the terminal room to work on a project. The terminal room has shared systems owned by the school that are on the network. These systems have been used by other students before, so their security posture is unknown 😬 The student wants to check whether a system is currently in compliance with the school's security policies before doing any work, so she requests a posture assessment. The NEA Server performs an initial assessment of the system and determines that it is compliant, but the anti-virus protection is not in use. The student gets an advisory response saying the system's anti-virus software is turned off, but that otherwise it complies with the school's policy. She turns on the anti-virus software, starts a scan, and, once it finishes, decides to trust the system with her work 🌈✨
6.1.2.2. Possible Flows and Protocol Usage
here's the flow through the NEA reference model for the student and the terminal room shared system 💻
- The student triggers the Posture Broker Client on the computer system in the terminal room to initiate a posture assessment. 🌟
- The Posture Broker Client establishes a session with the Posture Broker Server, which causes an assessment to be triggered. 🤝
- The Posture Broker Server detects the new session and consults policy to determine which Posture Validators to involve in the assessment. The Posture Broker Server decides to employ several Posture Validators, including the anti-virus Posture Validator. 🧠
- The Posture Validators involved create PA messages containing requests for particular attributes that describe the terminal room computer, based on the school's security policy. 📝
- The Posture Broker Server assembles a PB message including each of the PA messages from the Posture Validators. 📦
- The Posture Transport Server sends the PB message to the Posture Transport Client, where it is passed on to the Posture Broker Client. 🚀
- The Posture Broker Client on the student's computer de-multiplexes the PA messages and delivers them to the corresponding Posture Collectors. 🔓
- The Posture Collectors consult privacy policy to decide what information to share with the Server. If it's allowable, each Collector returns a PA message containing the requested posture to the Posture Broker Client. 🛡️
- 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. 💌
- The Posture Broker Server separates and distributes the Posture Collector PA messages to the associated Posture Validators. 🗂️
- The Posture Validators determine whether the attributes containing the posture included in the PA message are compliant with their policies, and return 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 it includes attributes describing how to activate the software. 🦠
- 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 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. ⚖️
- The Posture Transport Server sends the PB message to the Posture Transport Client, which provides the message to the Posture Broker Client. 📨
- 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 compliant, but that an advisory was included. 📢
- The Posture Broker Client provides the PA message with the remediation attributes to the anti-virus Posture Collector, which interacts with the user to explain how to turn on anti-virus to improve the local protections. 🛠️
- The student turns on the anti-virus software, and upon completion steps 1-10 are repeated. 🔄
- 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. 🥳
- The Posture Broker Client receives the successful global assessment decision in the PB message, and the student now uses the computer for her assignment. 🎀💅
6.1.2.3. Impact on Requirements
these are the big requirement vibes from this example 👑
- Voluntary endpoint requested initial assessment,
- Successful (compliant) global assessment decision included in PB message with a PA message containing an advisory set of attributes for remediation.
6.2. Posture Reassessment
okay, so reassessments can happen anytime after an endpoint has been admitted to the network following a successful initial NEA assessment 🔁 They may be event-based, such as when posture changes are detected by the NEA Client, or when changes are detected by network infrastructure, like 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 ⏰💖
6.2.1. Triggered by NEA Client
this use case is the endpoint being proactive, and I'm obsessed 🫶 Software on the endpoint, or a user, can determine that a reassessment of the system is required. There are a bunch of good reasons why this might be useful, including: changes in its previously reported posture, detection of potentially suspicious behavior, or even letting the system periodically poll the NEA Server to check its condition against the latest policies 🦋✨
6.2.1.1. Example
okay so picture the HR department's desktops 💻 They've got a history of sketchy security habits and getting compromised, so the HR department administrator installs software on every desktop to keep an eye on whether the security protective mechanisms are actually being used 👀 One day an HR person accidentally switches off the desktop firewall 😭 The monitoring process notices the firewall is missing and contacts the NEA Server to ask for a reassessment of firewall compliance. The NEA Server replies that the firewall must be reactivated to stay on the network 🚫 The NEA Client explains the decision to the user and shows them how to turn the firewall back on. The HR person restarts the firewall and asks to rejoin the network 🎀✨
6.2.1.2. Possible Flows & Protocol Usage
Here's how the message flow goes through the NEA reference model for the HR department example 💜
- The desktop monitoring software, which might act as a Posture Collector, triggers the Posture Broker Client to start a posture reassessment. The Posture Broker Client builds a PB message that holds a PA message saying the desktop firewall has been disabled 🔥
- The Posture Broker Client sends the PB message to the Posture Broker Server 📨
- The Posture Transport Client sends the PB message to the Posture Transport Server over the PT protocol 🚚
- The Posture Broker Server gets the PB message and forwards the PA message to the firewall Posture Validator for evaluation 🧐
- The firewall Posture Validator decides the endpoint is no longer compliant because its firewall is off 🙅♀️
- The Posture Validator generates a PA message with attributes that show a non-compliant posture assessment result, plus remediation instructions for turning the firewall back on 🛠️
- The Posture Validator passes the PA message with the posture assessment result to the Posture Broker Server so it can respond to the NEA Client 💌
- The Posture Broker Server builds a PB message that includes a global assessment decision of non-compliant and the PA message from the firewall Posture Validator 📦
- The Posture Transport Server carries the PB message to the Posture Transport Client, which hands it to the Posture Broker Client 🚛
- The Posture Broker Client processes the attribute holding the global assessment decision it got from the NEA Server and shows the non-compliance messages to the user 👀
- The Posture Broker Client forwards the PA message to the firewall Posture Collector, which displays the remediation instructions for turning the desktop firewall back on 🧯
- The user gets prompted to start a reassessment once they've finished the remediation 🙋♀️
- After the remediation is done, the NEA Client starts a new reassessment request, and steps 1-4 repeat. This time the firewall Posture Validator decides the endpoint is compliant and returns a successful posture assessment decision 🎉
- The Posture Broker Server builds a PB message with a global assessment decision of compliant and sends it back to the NEA Client 🥳👑
6.2.1.3. Impact on Requirements
These are a few different parts of this use case example that might need to be factored into the requirements 🌿
- Voluntary, endpoint (software) initiated posture reassessment request
- NEA Server requests specific firewall-oriented Posture Attributes
- NEA Client (firewall Posture Collector) interacts with user to remediate problem
6.2.2. Triggered by NEA Server
Okay, this one's the server being the main character 👑 Especially for reassessment, the NEA Server may start a specific or complete reassessment of one or more endpoints. The trigger can be:
- Time (periodic)
- Event occurrence
- Policy updates
6.2.2.1. Example
Picture an enterprise that needs employees on the network to always stay up to date with security-critical operating system patches 🩷 A marketing employee joins the network and does an initial assessment, and the laptop passes 💅 Several hours later, a major operating system vendor releases a set of patches that fix a serious vulnerability being exploited on the Internet 😱
The enterprise administrators make the patches available and change the network policy so they have to be installed by 5 PM 🕔 That policy change makes the NEA Server ask for a reassessment to figure out which endpoints are affected and missing the patches. The marketing employee's laptop gets reassessed and is found to need the patches. A remediation advisory goes out and is shown to the employee, explaining how to get the patches and that they must be installed by 5 PM ⏰ The employee immediately downloads and installs the patches and gets an assertion that all patches are now installed 🙌
At 5 PM, the enterprise runs another reassessment of all the impacted endpoints to see if they're compliant now 🕔✨ The marketing employee's laptop gets reassessed and presents the assertion that the patches are installed, so it's determined to be compliant 💖
6.2.2.2. Possible Flows and Protocol Usage
Here's the message flow through the NEA reference model for the example above 🧠
- The marketing employee joins the network and completes an initial assessment, which gives a compliant decision 🥰
- The Enterprise Administrator sets up an operating system patch policy saying recent patches are required on all endpoints by 5 PM to prevent serious vulnerabilities 📋
- The NEA Server's operating system patch Posture Validator notices the policy change. It creates a PA message that requests attributes describing the OS patches in use, and it triggers the Posture Broker Server to start a posture reassessment of all endpoints connected to the network 📣
- The Posture Broker creates a PB message that includes the PA message from the operating system patch Posture Validator 📦
- The Posture Broker Server gradually sets up a session with each available NEA Client 🤝
- The Posture Broker Server sends the PB message to the Posture Broker Client 📬
- The Posture Transport Server carries the PB message to the Posture Transport Client over the PT protocol 🚚
- The Posture Broker Client gets the PB message and forwards the PA message to the operating system patch Posture Collector 🎁
- The operating system patch Posture Collector figures out which OS patches are on the endpoint. If its disclosure policy allows it, it creates a PA message with the patch information attributes 🕵️♀️
- The Posture Broker Client sends a PB message that includes the operating system patch PA message 💌
- The Posture Transport Client carries the PB message to the Posture Transport Server, which passes it to the Posture Broker Server 🛤️
- The Posture Broker Server gets the PB message and delivers the PA message to the operating system patch Posture Validator 📥
- The operating system patch Posture Validator pulls out the attributes describing the current OS patches from the PA message and uses those values to decide whether the endpoint is compliant with the new policy. It decides the endpoint is not compliant because the new OS patches aren't installed 🚫
- The Posture Validator generates a PA message with attributes saying the posture assessment decision is non-compliant, plus attributes with remediation instructions so the endpoint can download the required OS patches 📝
- The Posture Validator passes the posture assessment result to the Posture Broker Server along with its PA message 🎀
- The Posture Broker Server generates a global assessment decision and sends a PB message with that decision and the operating system patch Posture Validator's PA message 🧾
- The Posture Transport Server carries the PB message to the Posture Transport Client, which passes it to the Posture Broker Client 🚛
- The Posture Broker Client processes the Result Attribute it got from the NEA Server and shows the non-compliance decision to the user 🙈
- The Posture Broker Client forwards the PA message with the remediation instructions to the operating system patch Posture Collector. The Posture Collector walks the user through how to become compliant, which includes downloading the right OS patches to prevent the vulnerability 🛡️
- The marketing employee installs the required patches and is now compliant 💪✨
- The NEA Client triggers a reassessment of the operating system patches, which causes many of the steps above to repeat. 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 asserting OS patch compliance with 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 🔐
- This time, when the operating system patch Posture Collector receives the PA message with the reusable compliance-asserting attributes, it caches them for future use 🗃️
- Later at 5 PM, the NEA Server triggers a gradual reassessment to check compliance with the patch advisory. When the operating system patch Posture Collector gets the request for posture information (like in step 9 above), it returns the cached assertions instead of specific OS patch information to show that the patches have been installed, rather than working out every patch on the system 🕔
- When the operating system patch Posture Validator gets the PA message with the assertions, it can tell they're authentic and acceptable assertions instead of specific posture. It returns a compliant posture assessment decision, so the laptop stays on the network 🥳🦋
6.2.2.3. Impact on Requirements
Here are the different aspects of this use case example that might need to go into the requirements 💖
- Server-initiated reassessment required due to urgent patch availability
- NEA Client submits reusable assertion attributes instead of posture that patch is installed
- NEA Server capable of recognizing previously issued assertion attributes are sufficient instead of posture
7. Requirements ✨
Okay bestie, this section is the checklist the NEA WG used to judge and compare candidate protocols for PA, PB, and PT 📋. Most of these are about features a protocol needs to be able to offer, so a deployer can decide whether to use them. This section does not say which features have to actually get used in a deployment 💅.
For example, a requirement (MUST, SHOULD, or MAY) might exist for cryptographic security protections to be available from each protocol. That doesn't mean a deployer has to use all of them, or even any, if they think their environment already has other protections that are good enough 🫶.
7.1. Common Protocol Requirements 🌈
These are the common requirements that apply to the PA, PB, and PT protocols in the NEA reference model 🦋:
C-1NEA protocols MUST support multiple round trips between the NEA Client and NEA Server in a single assessment.C-2NEA protocols SHOULD provide a way for both the NEA Client and the NEA Server to initiate a posture assessment or reassessment as needed.C-3NEA 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-4The 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-5The 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-6NEA 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-7The protocols MUST support efficient transport of a large number of attribute messages between the NEA Client and the NEA Server.C-8NEA protocols MUST operate efficiently over low bandwidth or high latency links 💜.C-9For any strings intended for display to a user, the protocols MUST support adapting these strings to the user's language preferences 🌸.C-10NEA protocols MUST support encoding of strings in UTF-8 format [UTF8].C-11Due 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 😭.
7.2. Posture Attribute (PA) Protocol Requirements 🎀
The Posture Attribute (PA) protocol defines the transport and data model for carrying 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 🫧.
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. They just mean the candidate protocols are capable of offering the property if it should be needed 💖.
PA-1The PA protocol MUST support communication of an extensible set of NEA standards defined attributes. These attributes will be distinguishable from non-standard attributes.PA-2The 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-3The 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-4The 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-5The 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-6The PA protocol MUST be capable of carrying attributes that contain non-binary and binary data, including encrypted content 🦋.
7.3. Posture Broker (PB) Protocol Requirements 🧸
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 🔁.
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 🏆.
The PB protocol also aggregates and transports advisories and notifications, such as remediation instructions (e.g., patch references), from one or more Posture Validators 📣.
The requirements for the PB protocol are:
PB-1The 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-2The 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-3The 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-4The 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-5The 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-6The PB protocol MUST support grouping of attribute messages optimize transport of messages and minimize round trips 🚀.
7.4. Posture Transport (PT) Protocol Requirements 🚚
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 🛡️.
This section defines the requirements that candidate PT protocols must be capable of supporting 💜.
PT-1The 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-2The 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-3The 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-4The PT protocol SHOULD be able to run over existing network access protocols such as 802.1X and IKEv2 🔌.PT-5The 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)) 🌷.
8. Security Considerations 🔐✨
Okay bestie, this is the part where we get real about what could go wrong 😭 This document only defines the functional requirements for the PA, PB, and PT protocols used for Network Endpoint Assessment. It doesn't pick a protocol stack or specific technologies, so this section highlights the security issues that may apply to NEA in general or to particular parts of the NEA reference model 💅
Note that a bunch of topics are outside the NEA WG's scope and this specification (see section 3.1), but it's still super important that those mechanisms are protected from attack 🫶 For example, the methods of triggering an assessment or reassessment are out of scope, but they should still be appropriately protected from attack. Like, imagine an attacker hiding the event that says a NEA Server policy change has happened 💀 That's a whole villain arc.
NEA wants to facilitate detection and corrective actions so cooperating endpoints can become compliant with network compliance policies 🌸 The idea is that these policies let deployers detect out-of-date, inactive, or absent security mechanisms on an endpoint that might leave it more vulnerable to known attacks. If an endpoint is more vulnerable to compromise, it's riskier to have it on the network next to other valuable assets. So by proactively assessing cooperating endpoints before they enter the network, deployers can improve their resilience to attack prior to network access. Reassessments of cooperating endpoints on the network can also help make sure security mechanisms stay in use and up to date with the latest policies 🦋
NEA fully recognizes that not all endpoints will be cooperating by providing their valid posture (or any posture at all) 🙈 This might happen if malware is influencing the NEA Client or policies, which means a trustworthy assessment isn't possible. That could result in an endpoint that introduces threats to the network and other endpoints getting admitted, even though it passed the NEA compliance assessment. ngl that's a total plot twist 😭🔥
8.1. Trust 🤝
Network Endpoint Assessment is all about assessing the posture of endpoints that are entering or already on the network against compliance policies, so they're adequately protected. Therefore, there must be an implied distrust of endpoints until there's reason to believe (based on posture information) that they're protected from the threats addressed by compliance policy and can be trusted not to pass those threats along to other endpoints 🧐 On the network provider side, the NEA Client normally is expected to trust the network infrastructure systems not to misuse any disclosed posture information (see section 9) or any remediation instructions given 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 💖
Between the NEA Client and Server there's a network that is not assumed to be trustworthy 👀 So very little about the network is implicitly trusted, beyond its willingness and ability to carry the exchanged messages in a timely manner. How much trust each component of the NEA reference model gets is deployment specific. The NEA WG intends to provide security mechanisms that reduce the amount of trust a deployer has to assume 🎀 The following sections go through each area in more detail.
8.1.1. Endpoint 💻
For NEA to properly operate, the endpoint needs to be trusted to accurately represent its requested security posture to the NEA Server. By NEA WG charter, the NEA reference model doesn't explicitly specify how to detect or prevent lying endpoints that intentionally misrepresent their posture 🙃 Similarly, detecting malware (e.g., root kits) that can trick the Posture Collectors into returning incorrect information is a topic for research and standardization outside the IETF (e.g., Trusted Computing Group [TCG]). The model doesn't specifically address it. Still, if those mechanisms are used in a deployment, the NEA reference model should be able to accommodate these technologies. They can communicate over PA to Posture Validators, or work orthogonally to protect the NEA Client from attack and assure that Posture Collectors can view the actual posture 🛡️
Besides trusting the integrity of the NEA Client and its ability to accurately collect and report Posture Attributes about the endpoint, we try to limit any other assumed trust 🌈 Most NEA usage models 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 the 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 not to falsify the results of the posture evaluation 😳
Generally, the endpoint should not trust network communications (e.g., inbound connection requests) unless that 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 require some level of trust, particularly when the NEA Server initiates them (reassessment). The degree of trust can be limited by using strong security protections on the messages, as dictated by the network deployer and the endpoint user/owner policy 🔐
8.1.2. Network Communications 📡
Between the NEA Client and Server, there may be a variety of device types helping the communication path along 🧚 Some of those devices may serve as intermediaries (e.g., simple L2 switches), so they may have the opportunity to observe and change the message dialogs. Yikes 😬
The intermediary devices fall into a few major categories that affect how much we trust them. 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 try to disrupt the NEA deployment (e.g., with denial of service (DoS)) 🌊
Second, some intermediary devices may be part of the access control layer of the network. We trust them to enforce the policies they're given as a result of a NEA assessment, including remediation, isolation, and access controls 🚧 These devices may also fill other types of roles described in this section 💜
Third, some devices may act as a termination point or proxy for the PT carrier protocol. Frequently, the carrier protocol for PT is expected to terminate on the NEA Client and Server, so it will be co-resident with the PT endpoints. If that expectation isn't met in a deployment, we must trust the termination device to accurately proxy the PT messages into the next carrier protocol without alteration (e.g., if inner EAP method messages are transitioned from an EAP [EAP] tunnel to a RADIUS session) 🍓
Fourth, many networks include infrastructure such as IDS/IPS devices that monitor the network and take corrective action when suspicious behavior is observed 👁️ These devices may have a relationship with the NEA Server that is not within the scope of this specification. Devices the NEA Server trusts to provide security information that might affect its decisions are trusted to operate properly and not cause the NEA Server to make incorrect decisions ✨
Finally, other types of intermediary devices may exist between the NEA Client and Server to service network functions besides NEA 🕵️♀️ These devices might passively eavesdrop on the network, archive information for future purposes (e.g., replay or privacy invasion), or more actively attack the NEA protocols. Because these devices don't play a role in facilitating NEA, it's essential that NEA deployers not be forced to trust them for NEA to reliably operate. So 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 🛡️💅
8.1.3. NEA Server 🖥️
The NEA Server (including potentially remote systems providing posture validation services) is generally trusted to apply the specified assessment policies, and it must be protected from compromise 🏰 It's essential that NEA Server deployments properly safeguard these systems from a variety of attacks coming from the network and from endpoints, so they keep operating properly 🫶
Even though we need to trust the NEA Server's operation to some degree, rigorous security architecture, analysis, monitoring, and review should make sure its network footprint and internal workings are protected from attack 🔍 The network footprint includes 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 protection from malware attacking intra-NEA Server communications, the NEA Server's 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 messages exchanged with the endpoint. The NEA reference model doesn't try to address integrity protection of the operating system or other software supporting the NEA Server 🙅♀️
One interesting example is when some components of the NEA Server physically live in different systems 🌍 This might happen when a Posture Validator (or a remote backend server used by a local Posture Validator) lives on a different system from the Posture Broker Server. Similarly, the Posture Broker Server might sit on a separate system from the Posture Transport Server. When there's physical separation, 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, they need to be guarded against eavesdropping, forgery, and replay 🧨 Posture Validators may also wish to minimize their trust in the Posture Broker Server beyond its ability to properly send and deliver PA messages. Posture Validators could use end-to-end PA security to verify the authenticity and protect the integrity and/or confidentiality of the PA messages exchanged 🦋
When PA security is used, each Posture Validator must be able to trust the integrity and potentially the confidentiality of its trust anchor policies 🌸
8.2. Protection Mechanisms at Multiple Layers ✨
okay so bestie, the requirements basically want every NEA candidate protocol across the whole reference model to be able to bring strong security mechanisms, depending on how the deployment is set up 🔒💖. Sometimes those mechanisms look like they overlap or repeat each other, and that's actually giving defense in depth 🛡️. They can be stacked together on purpose. BUT (and this is the tea 🫖) because the protocols are layered, each set of protections gives you slightly different perks and a different level of granularity, so one isn't a copy of another 🎀.
Like, a deployer might want to encrypt traffic at the PT layer so an eavesdropper can't do certain kinds of traffic analysis or interception 👀. They could also selectively encrypt the messages that carry an endpoint's posture, so the info stays confidential all the way to its Posture Validator 🥹✨. This is especially cute when the Posture Validator is not on the same box as the NEA Server, because then the posture travels over extra network segments after the PT protections have already been applied 🌐. Another reason is so the Posture Validator can authenticate the Posture Collector (or the other way around) 🤝💅.
Different use cases and environments will probably change how strong the security mechanisms are and which ones get picked for an assessment 🌈. The whole goal of the NEA requirements is to push people toward technologies and protocols that can actually cover a wide variety of assessment types 💜🧚.
8.3. Relevant Classes of Attack 🙈
There are a bunch of attacks that can hit the NEA protocols and assessment technologies 😭. This section is NOT a full security analysis (sorry, not sorry 💀). It just spotlights a few attacks that shaped the requirements and that deployers should keep in mind when they pick protective mechanisms in the NEA reference model 🔍.
As we already talked about, the requirements include a bunch of protective mechanisms for candidate NEA protocols 🧁. Different use cases and environments might make deployers skip some of them, and that's allowed, but they need to understand the deployment could become vulnerable to some classes of attack if they do 😬. It's always a balancing act of risk vs. performance, usability, manageability, and other factors ⚖️✨.
The following types of attacks apply to network protocols defined in the reference model, so deployers should totally consider them 💅🔥.
8.3.1. Man-in-the-Middle (MITM) 🕵️♀️
Okay this one is so dramatic 😭. A MITM attack on a network protocol happens when a third party inserts itself between two communicating entities without anyone noticing, and then gets some benefit from being in the middle of their conversation 🫣. For example, a malware-infested system might want to join the network by replaying the posture of a clean endpoint that's entering the network 🦠. This could happen if the system inserts itself into an assessment message dialog and actively proxies it 🎭. The damage a MITM can do can be limited or prevented by picking the right protocol protective mechanisms 🛡️💖.
For example, the requirement that PT be capable of supporting mutual authentication before any endpoint assessment message dialogs stops the attacker from inserting itself as an active participant (a proxy) without being detected 🙅♀️. This assumes the attacker doesn't have credentials that would convince either party it's legit 🔐. Reusable credentials should not be exposed on the network, so the MITM has no way to impersonate either party 🙈. The PT requirement for confidentiality-protected (encrypted) communications, tied to that authentication, stops a passive MITM from eavesdropping, watching the message dialog, and keeping a record of the conformant posture values for later 👀📼. The PT requirement for replay prevention stops a passive MITM from later setting up a new session (or hijacking an existing one) and replaying message dialogs it saw before 🔁💅.
Now, if a non-compliant, active MITM can trick a clean endpoint into handing over its posture information, and that MITM has legit credentials, it might be able to look like it has compliant posture to a NEA Server even though it doesn't 😳. For example, a non-compliant MITM could connect and authenticate to a NEA Server. When the NEA Server asks for posture information, the MITM could ask the clean endpoint for that same posture 🔄. If the clean endpoint trusts the MITM to do a reassessment and is willing to share the requested posture, the MITM could grab that posture and pass it along to the NEA Server 🫠. To stop this kind of MITM attack, the NEA protocols would need to offer a strong (cryptographic) binding between the posture information and the authenticated session with the NEA Server, so the NEA Server knows the posture came from the endpoint that authenticated 🔐💜. A strong link between where the posture came from and the endpoint that authenticated may be doable, so the NEA WG should prefer it 🌸.
8.3.2. Message Modification ✏️
Without message integrity protection, an attacker who can intercept a message might be able to change its contents and cause a wrong decision to be made 😱. For example, the attacker could change the Posture Attributes so they always show incorrect values, which would stop a compliant system from joining the network 🚫. Unless the NEA Server could detect that change, the attacker could keep large numbers of clean systems out 😤. The flip side is that the attacker could let a malware-infested machine in by changing the sent Posture Attributes to show compliant values, which hides the malware from the Posture Validator 🦠🙈. The attacker could even infect compliant endpoints by sending malicious remediation instructions that, when carried out, would install malware on the endpoint or turn off security mechanisms 💀.
To protect against these attacks, PT includes a requirement for strong integrity protection (for example, a protected hash like a Hashed Message Authentication Code (HMAC) [HMAC] of the message), so any change to a message would be detected 🕵️♀️✨. PA has 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 lives on another system behind the NEA Server 🎀🫶.
It's important that integrity protection schemes use fresh secret information (the kind the attacker doesn't know) that's bound to the authenticated session, like an HMAC using a derived fresh secret associated with the session 🔑🔥. Including freshness information lets the parties guard against some forms of message replay attacks that would otherwise use secret information from earlier sessions 🔁💅.
8.3.3. Message Replay or Attribute Theft 🦋
An attacker might sit on the network, record message dialogs or attributes from a compliant endpoint, and reuse them later against the same NEA Server 📼. Or they might just collect them to build an inventory of software running on other systems, watching for known vulnerabilities 👀💀. The NEA Server needs to be able to detect a replay of posture, or the model has to make sure the eavesdropper can't get the information in the first place 🧐. That's why the PT protocol is required to provide confidentiality and replay prevention 🔐🌈.
The cryptographic protection against disclosure of the PT, PB, or PA messages stops a passive listener from seeing the exchanged messages, so the info can't be stolen for later use 🙌. BUT an active attacker might still be able to replay an encrypted message if there's no strong link to the originating party or session 😬. By tying the encrypted message dialog to the authentication event, and using per-transaction freshness and keying exchanges, a replay of the encrypted transaction is prevented 🔒✨.
8.3.4. Other Types of Attack 🌸
This section doesn't claim to be an exhaustive list of attacks against the NEA reference model 🙃. Several types of attack will get easier to understand and analyze once the NEA WG has written specifications for the specific technologies and protocols chosen for NEA 📚. Denial of Service (DoS) is one of those areas 🌊. Right now it isn't practical to try to define every potential exposure in the NEA protocols, so that analysis should go into the Security Considerations sections of the selected NEA protocols 📝💖.
That said, it's really important that the NEA Server be resilient to DoS attacks, because an outage could hit large numbers of endpoints that want to join or stay on the network 😭🚨. The NEA reference model expects PT to have some amount of DoS resilience, and expects PA and PB to build on that base with their own protections 🧱. To help narrow the window for unauthenticated parties to attack, NEA Servers are envisioned to use PT protocols that enable early mutual authentication of the requesting endpoint, as one technique for filtering out attacks 🚧✨.
Attacks that happen after authentication at least come from sources with valid credentials, so they could potentially be held accountable 🧾. In the same way, NEA protocols should offer strong replay protection to prevent DoS-based attacks that rely on replayed sessions and messages 🔁🛡️. Posture assessment should be strongly linked to the Posture Transport authentications that happened, to make sure 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 has been established 🥺. This and other resource- and protocol-based attacks can be evaluated once the NEA technologies and their cryptographic use have been selected 🦄💜.
9. Privacy Considerations ✨
okay bestie, so NEA tech is genuinely useful for orgs that run their own networks and hand out their own devices 💻. but the same tools could also be used to invade someone's privacy if people misuse them 😬. this section covers some of the privacy concerns that come with deploying it, plus a few tips for implementers 🫶
NEA gives the network way more visibility into an endpoint's configuration 👀. that's kind of the point, because the network can factor in how strong the endpoint's security is when deciding what it gets to access 🔐. but that same transparency could be used to push restrictive policies that hurt the user, like limiting what software they're allowed to pick or digging into what they've done on the device in the past or present 🙅♀️. not it 💅
The NEA WG only scoped its protocols to situations where the endpoint and the network are owned by the same party, or where the endpoint owner has clearly agreed to disclosure and compliance with the network owner 📋. this is a super familiar setup for governments, schools, and lots of companies that give their employees devices to do their jobs 💼. in many of these cases the enterprise buys and owns the endpoint, and they usually keep the right to audit it and even dictate what it can be used for 🧐. NEA lets them automate looking inside an endpoint, and that info can be tied to network access controls so the endpoint's use gets limited if it doesn't meet minimum compliance levels 🚦
In these environments the employee's personal privacy may be pretty reduced, depending on local laws and customs 🤷♀️. BUT if the endpoint belongs to the user, or local laws protect the user's rights even on someone else's device, then the NEA implementation has to let the user control what endpoint info gets shared with the network 🎀. these controls might stop or limit the user from reaching certain networks or protected resources, and that's totally fine, but it has to be the user's choice 🦋
9.1. Implementer Considerations
the NEA WG isn't defining NEA Client policy content standards or setting requirements on parts of an implementation outside the network protocols 📦. however, they've put together some guidance to encourage privacy-friendly implementations that work beyond the enterprise setting we just talked about 🌈
NEA Client implementations are encouraged to offer users an opt-in policy before they share their endpoint's posture information 🙋♀️. the opt-in should be per-user and per-NEA Server, so each user can decide which networks get to see posture info on their system 🔍. for networks that are allowed to assess the endpoint, the user should be able to set granular restrictions on which types and specific attributes Posture Collectors are allowed to disclose 🎯. Posture Validator implementations are discouraged from defaulting to wild-carded requests for posture, since that could lead to overexposing info (see section 9.2) 🙅♀️. instead, Posture Validators should, by default, only request the specific attributes they actually need to do their assessment ✨
requests for attributes that aren't explicitly allowed (or specifically disallowed) to be shared should trigger a user notification and/or a log record 🔔. that way the user can figure out whether the service is doing something sketchy, or whether they're fine sharing that extra info to get access 👀. some products might consider policy-driven prompts asking the user for permission, with a clear description of the posture info being requested before it gets sent to the NEA Server 💬
the endpoint's owner is expected to be able to set disclosure policies that can override or influence the user's policies on which attributes the network can see 👑. if the owner's disclosure policy allows broader posture availability than the user's policy, the implementation should give the user some feedback so they understand what's going on and can decide whether to use the endpoint in those situations 💖
in a system like this, the user's policy-authoring interface has to be easy to understand and clearly spell out the current disclosure policy, including any influence from the owner's policy 📝. users should be able to tell what posture the network can see and the general impact of that info being known 🧠. to keep the list of restrictions short, a conservative default disclosure policy might make sense, something like "that which is not explicitly authorized for disclosure is not allowed," which helps avoid accidental leaks of info 🔒
NEA Server implementations should show newly subscribing endpoints a disclosure statement that clearly says:
- What information is required
- How this information will be used and protected
- What local privacy policies are applicable
this info helps subscribing users decide whether sharing it is okay, given their local laws and customs 🫶
9.2. Minimizing Attribute Disclosure
one big issue in designing the NEA reference model and protocols is letting endpoints disclose only the minimum info needed to prove they comply with network policies 🎯. there are a few models for how the disclosed attribute set could get established, and each one has privacy benefits and issues that product developers should think about 🤔. this section sums up three potential models for how attribute disclosure might work in NEA products, along with the privacy implications that could come with each one 💅
the first model is easy to build and deploy, but it has privacy issues and possibly latency and scalability problems 😬. it basically sets the local policy to send all known NEA Posture Attributes every time an assessment happens 📤. that might simplify deployment, but it exposes a ton of info that probably doesn't matter for the security assessment and could cause privacy issues 🙈. for example, does the enterprise really need to know whether someone's using Firefox instead of another browser during a security posture check? 🦊 probably not, bestie
the second model uses out-of-band provisioning of the disclosure policy to every endpoint 📬. here the enterprise sets a policy that a particular list of attributes must be provided whenever a NEA exchange happens 📋. endpoint privacy policy can filter that list, but those changes could mean the endpoint doesn't get network or resource access 😭. this model makes the network exchange simpler, since the endpoint always sends the filtered list when a particular network challenges it 🧩. the catch is that it needs an out-of-band management protocol to set up and manage the NEA disclosure policies on all systems 🛠️
the third model skips pre-provisioning altogether by letting the NEA Server specifically ask for the attributes it needs 🙌. it's kind of like provisioning the policy during the NEA exchanges, so it's way easier to manage 🥰. this model lets the NEA Server ask for attributes step by step, based on the values of earlier attributes 🪜. note that even here, the NEA protocols aren't meant to be a general-purpose query language 🚫. they just let the NEA Server request specific attributes, since only the defined attributes can be requested in the first place 📚. for example, an enterprise might ask about the OS version in the first message, and after learning the system runs Linux, ask for a different set of Linux-specific attributes than it would for a Windows machine 🐧🪟. this approach might cut down on the attributes sent over the network when the assessment is complex, like figuring out which patches an OS is missing 🩹
in every model, the user could set up per-network privacy filter policies that the NEA Client enforces, to stop personal or irrelevant attributes from being disclosed to a particular network 🛡️. these filters protect the user's privacy, but they might mean the user doesn't get access to the asset (or network) they want, or only gets limited access 🥺
10. References
10.1. Normative References
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003.10.2. Informative References
[802.1X] IEEE Standards for Local and Metropolitan Area Networks:
Port based Network Access Control, IEEE Std 802.1X-2001,
June 2001.
[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.
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[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.
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[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/11. Acknowledgments 🌸
the authors want to give a huge shoutout to the NEA Working Group members who contributed to the earlier requirements and problem statement documents that shaped this spec 🫶💜: 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 ✨👑
Authors' Addresses ✨
Okay bestie, here are the humans behind this doc! 🫶 Five authors from Symantec, Intel, Avaya, Cisco, and Nevis Networks. Their contact details are below, exact as written:
Paul Sangster
Symantec Corporation
6825 Citrine Dr
Carlsbad, CA 92009 USA
Phone: +1 760 438-5656
EMail: 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
Mahalingam Mani
Avaya Inc.
1033 McCarthy Blvd.
Milpitas, CA 95035 USA
Phone: +1 408 321-4840
EMail: 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
Joseph Tardo
Nevis Networks
295 N. Bernardo Ave., Suite 100
Mountain View, CA 94043 USA
EMail: joseph.tardo@nevisnetworks.comFull Copyright Statement 💅
Copyright (C) The IETF Trust (2008). 💜
This document is subject to the rights, licenses and restrictions in BCP 78. Apart from what BCP 78 says, the authors keep all of their rights. 🦋
The document and everything in it are provided "AS IS". The contributor, the organization they represent or are sponsored by (if any), the Internet Society, the IETF Trust, and the Internet Engineering Task Force all disclaim every warranty, whether express or implied. That includes, but isn't limited to, any warranty that using the information won't infringe any rights, and any implied warranty of merchantability or fitness for a particular purpose. 😭
Translation: the info is handed over as-is, and nobody is promising it'll work for your specific use case or stay out of anyone's IP lane. Read it with that in mind! 💀
Intellectual Property 🔥
The IETF doesn't take a side on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid, or how far they reach. It also doesn't say whether any license under those rights is available, or whether it's even possible to get one. It hasn't independently checked for such rights either. 🙈 If you want the rules on rights in RFC documents, check out BCP 78 and BCP 79. 📚
Copies of IPR disclosures made to the IETF Secretariat, along with any assurances of licenses that may be available, are on the IETF online IPR repository at http://www.ietf.org/ipr. The same goes for the results of any attempt to get a general license or permission to use those proprietary rights, which implementers or users of this specification can look up there. 🌈
The IETF invites anyone to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. 💖 Send that info to ietf-ipr@ietf.org. Be the helpful bestie who speaks up! 🫶✨
📦 where this page comes from
- ietf: rfc5209 2008-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms