RFC 5209
Network Endpoint Assessment (NEA): Overview and Requirements
Pages: 53
Informational
Informational
Part 1 of 3 – Pages 1 to 10
Network Working Group P. Sangster Request for Comments: 5209 Symantec Category: Informational H. Khosravi Intel M. Mani Avaya K. Narayan Cisco Systems J. Tardo Nevis Networks June 2008 Network Endpoint Assessment (NEA): Overview and Requirements Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.Abstract
This document defines the problem statement, scope, and protocol requirements between the components of the NEA (Network Endpoint Assessment) reference model. NEA provides owners of networks (e.g., an enterprise offering remote access) a mechanism to evaluate the posture of a system. This may take place during the request for network access and/or subsequently at any time while connected to the network. The learned posture information can then be applied to a variety of compliance-oriented decisions. The posture information is frequently useful for detecting systems that are lacking or have out-of-date security protection mechanisms such as: anti-virus and host-based firewall software. In order to provide context for the requirements, a reference model and terminology are introduced.
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
Endpoints connected to a network may be exposed to a wide variety of threats. Some protection against these threats can be provided by ensuring that endpoints conform to security policies. Therefore, the intent of NEA is to assess these endpoints to determine their compliance with security policies so that corrective measures can be provided before they are exposed to those threats. For example, if a system is determined to be out of compliance because it is lacking proper defensive mechanisms such as host-based firewalls, anti-virus software, or the absence of critical security patches, the NEA protocols provide a mechanism to detect this fact and indicate appropriate remediation actions to be taken. Note that an endpoint that is deemed compliant may still be vulnerable to threats that may exist on the network. NEA typically involves the use of special client software running on the requesting endpoint that observes and reports on the configuration of the system to the network infrastructure. The infrastructure has corresponding validation software that is capable of comparing the endpoint's configuration information with network compliance policies and providing the result to appropriate authorization entities that make decisions about network and application access. Some endpoints may be incapable of running the
NEA Client software (e.g., printer) or be unwilling to share information about their configuration. This situation is outside the scope of NEA and is subject to local policies. The result of an endpoint assessment may influence an access decision that is provisioned to the enforcement mechanisms on the network and/or endpoint requesting access. While the NEA Working Group recognizes there may be a link between an assessment and the enforcement of a resulting access decision, the mechanisms and protocols for enforcement are not in scope for this specification. Architectures, similar to NEA, have existed in the industry for some time and are present in shipping products, but do not offer adequate interoperability. Some examples of such architectures include: Trusted Computing Group's Trusted Network Connect [TNC], Microsoft's Network Access Protection [NAP], and Cisco's Cisco Network Admission Control [CNAC]. These technologies assess the software and/or hardware configuration of endpoint devices for the purposes of monitoring or enforcing compliance to an organization's policy. The NEA Working Group is developing standard protocols that can be used to communicate compliance information between a NEA Client and a NEA Server. This document provides the context for NEA including: terminology, applicability, problem statement, reference model, and use cases. It then identifies requirements for the protocols used to communicate between a NEA Client and NEA server. Finally, this document discusses some potential security and privacy considerations with the use of NEA. The majority of this specification provides informative text describing the context of NEA.1.1. Requirements Language
Use of each capitalized word within a sentence or phrase carries the following meaning during the NEA WG's protocol selection process: MUST - indicates an absolute requirement MUST NOT - indicates something absolutely prohibited SHOULD - indicates a strong recommendation of a desired result SHOULD NOT - indicates a strong recommendation against a result MAY - indicates a willingness to allow an optional outcome Lower case use of "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" carry their normal meaning and are not subject to these definitions.
2. Terminology
This section defines a set of terms used throughout this document. In some cases these terms have been used in other contexts with different meanings so this section attempts to describe each term's meaning with respect to the NEA WG activities. Assessment - The process of collecting posture for a set of capabilities on the endpoint (e.g., host-based firewall) such that the appropriate validators may evaluate the posture against compliance policy. Assertion Attributes - Attributes that include reusable information about the success of a prior assessment of the endpoint. This could be used to optimize subsequent assessments by avoiding a full posture reassessment. For example, this classification of attribute might be issued specifically to a particular endpoint, dated and signed by the NEA Server allowing that endpoint to reuse it for a time period to assert compliance to a set of policies. The NEA Server might accept this in lieu of obtaining posture information. Attribute - Data element including any requisite meta-data describing an observed, expected, or the operational status of an endpoint feature (e.g., anti-virus software is currently in use). Attributes are exchanged as part of the NEA protocols (see section 5.2). NEA recognizes a variety of usage scenarios where the use of an attribute in a particular type of message could indicate: o previously assessed status (Assertion Attributes), o observed configuration or property (Posture Attributes), o request for configuration or property information (Request Attributes), o assessment decision (Result Attributes), or o repair instructions (Remediation Attributes). The NEA WG will standardize a subset of the attribute namespace known as standard attributes. Those attributes not standardized are referred to in this specification as vendor-specific. Dialog - Sequence of request/response messages exchanged.
Endpoint - Any computing device that can be connected to a network.
Such devices normally are associated with a particular link layer
address before joining the network and potentially an IP address
once on the network. This includes: laptops, desktops, servers,
cell phones, or any device that may have an IP address.
Message - Self contained unit of communication between the NEA Client
and Server. For example, a posture attribute message might carry
a set of attributes describing the configuration of the anti-virus
software on an endpoint.
Owner - the role of an entity who is the legal, rightful possessor of
an asset (e.g., endpoint). The owner is entitled to maintain
control over the policies enforced on the device even if the asset
is not within the owner's possession. The owner may permit user
override or augmentation of control policies or may choose to not
assert any policies limiting use of asset.
Posture - Configuration and/or status of hardware or software on an
endpoint as it pertains to an organization's security policy.
Posture Attributes - Attributes describing the configuration or
status (posture) of a feature of the endpoint. For example, a
Posture Attribute might describe the version of the operating
system installed on the system.
Request Attributes - Attributes sent by a NEA Server identifying the
posture information requested from the NEA Client. For example, a
Request Attribute might be an attribute included in a request
message from the NEA Server that is asking for the version
information for the operating system on the endpoint.
Remediation Attributes - Attributes containing the remediation
instructions for how to bring an endpoint into compliance with one
or more policies. The NEA WG will not define standard remediation
attributes, but this specification does describe where they are
used within the reference model and protocols.
Result Attributes - Attributes describing whether the endpoint is in
compliance with NEA policy. The Result Attribute is created by
the NEA Server normally at the conclusion of the assessment to
indicate whether or not the endpoint was considered compliant.
More than one of these attributes may be used allowing for more
granular feature level decisions to be communicated in addition to
an overall, global assessment decision.
Session - Stateful connection capable of carrying multiple message
exchanges associated with (an) assessment(s) of a particular
endpoint. This document defines the term session at a conceptual
level and does not describe the properties of the session or
specify requirements for the NEA protocols to manage these
sessions.
User - Role of a person that is making use of the services of an
endpoint. The user may not own the endpoint so he or she might
need to operate within the acceptable use constraints defined by
the endpoint's owner. For example, an enterprise employee might
be a user of a computer provided by the enterprise (owner) for
business purposes.
3. Applicability
This section discusses the scope of the technologies being
standardized and the network environments where it is envisioned that
the NEA technologies might be applicable.
3.1. Scope
The priority of the NEA Working Group is to develop standard
protocols at the higher layers in the reference model (see section
5): the Posture Attribute protocol (PA) and the Posture Broker
protocol (PB). PA and PB will be designed to be carried over a
variety of lower layer transport (PT) protocols. The NEA WG will
identify standard PT protocol(s) that are mandatory to implement. PT
protocols may be defined in other WGs because the requirements may
not be specific to NEA. When used with a standard PT protocol (e.g.,
Extensible Authentication Protocol (EAP), Transport Layer Security
(TLS) [TLS]), the PA and PB protocols will allow interoperability
between a NEA Client from one vendor and a NEA Server from another.
This specification will not focus on the other interfaces between the
functional components of the NEA reference model nor requirements on
their internals. Any discussion of these aspects is included to
provide context for understanding the model and resulting
requirements.
Some tangent areas not shown in the reference model that are also out
of scope for the NEA working group, and thus this specification,
include:
o Standardizing the protocols and mechanisms for enforcing
restricted network access,
o Developing standard protocols for remediation of non-compliant
endpoints,
o Specifying protocols used to communicate with remote portions of
the NEA Client or Server (e.g., remote collectors or validators
of posture),
o Supporting a NEA Client providing posture for other endpoints
(e.g., a NEA Client on an Intrusion Detection System (IDS)
providing posture for an endpoint without a NEA Client),
o Defining the set of events or situations that might trigger a
NEA Client or NEA Server to request an assessment,
o Detecting or handling lying endpoints (see section 8.1.1 for
more information).
3.2. Applicability of Environments
Because the NEA model is based on NEA-oriented software being present
on the endpoint and in the network infrastructure, and due to the
nature of the information being exposed, the use of NEA technologies
may not apply in a variety of situations possible on the Internet.
Therefore, this section discusses some of the scenarios where NEA is
most likely to be applicable and some where it may not be.
Ultimately, the use of NEA within a deployment is not restricted to
just these scenarios. The decision of whether to use NEA
technologies lies in the hands of the deployer (e.g., network
provider) based upon the expected relationship they have with the
owners and users of potential endpoints.
NEA technologies are largely focused on scenarios where the owner of
the endpoint is the same as the owner of the network. This is a very
common model for enterprises that provide equipment to employees to
perform their duties. These employees are likely bound under an
employment contract that outlines what level of visibility the
employer expects to have into the employee's use of company assets
and possibly activities during work hours. This contract may
establish the expectation that the endpoint needs to conform to
policies set forth by the enterprise.
Some other environments may be in a similar situation and thus find
NEA technologies to be beneficial. For example, environments where
the endpoint is owned by a party (possibly even the user) that has
explicitly expressed a desire to conform to the policies established
by a network or service provider in exchange for being able to access
its resources. An example of this might be an independent contractor
with a personal laptop, working for a company imposing NEA assessment
policies on its employees, who may wish a similar level of access and
is willing to conform to the company's policies. NEA technologies
may be applicable to this situation.
Conversely, some environments where NEA is not expected to be applicable would be environments where the endpoint is owned by a user that has not agreed to conform to a network provider's policies. An example might include when the above contractor visits any public area like the local coffee shop that offers Internet access. This coffee shop would not be expected to be able to use NEA technologies to assess the posture of the contractor's laptop. Because of the potentially invasive nature of NEA technology, such an assessment could amount to an invasion of privacy of the contractor. It is more difficult to determine whether NEA is applicable in other environments, so the NEA WG will consider them to be out of scope for consideration and specification. In order for an environment to be considered applicable for NEA, the owner or user of an endpoint must have established a clear expectation that it will comply with the policies of the owner and operator of the network. Such an expectation likely includes a willingness to disclose appropriate information necessary for the network to perform compliance checks.4. Problem Statement
NEA technology may be used for a variety of purposes. This section highlights some of the major situations where NEA technologies may be beneficial. One use is to facilitate endpoint compliance checking against an organization's security policy when an endpoint connects to the network. Organizations often require endpoints to run an IT-specified Operating System (OS) configuration and have certain security applications enabled, e.g., anti-virus software, host intrusion detection/prevention systems, personal firewalls, and patch management software. An endpoint that is not compliant with IT policy may be vulnerable to a number of known threats that might exist on the network. Without NEA technology, ensuring compliance of endpoints to corporate policy is a time-consuming and difficult task. Not all endpoints are managed by a corporation's IT organization, e.g., lab assets and contractor machines. Even for assets that are managed, they may not receive updates in a timely fashion because they are not permanently attached to the corporate network, e.g., laptops. With NEA technology, the network is able to assess an endpoint as soon as it requests access to the network or at any time after joining the network. This provides the corporation an opportunity to check compliance of all NEA-capable endpoints in a timely fashion and facilitate endpoint remediation potentially while quarantined when needed.
NEA technology can be used to provide posture assessment for a range of ways of connecting to the network including (but not limited to) wired and wireless LAN access such as using 802.1X [802.1X], remote access via IPsec [IPSEC], or Secure Socket Layer (SSL) VPN, or gateway access. Endpoints that are not NEA-capable or choose not to share sufficient posture to evaluate compliance may be subject to different access policies. The decision of how to handle non-compliant or non-participating endpoints can be made by the network administrator possibly based on information from other security mechanisms on the network (e.g., authentication). For example, remediation instructions or warnings may be sent to a non-compliant endpoint with a properly authorized user while allowing limited access to the network. Also, network access technologies can use the NEA results to restrict or deny access to an endpoint, while allowing vulnerabilities to be addressed before an endpoint is exposed to attack. The communication and representation of NEA assessment results to network access technologies on the network is out of scope for this document. Reassessment is a second important use of NEA technology as it allows for additional assessments of previously considered compliant endpoints to be performed. This might become necessary because network compliance policies and/or endpoint posture can change over time. A system initially assessed as being compliant when it joined the network may no longer be in compliance after changes occur. For example, reassessment might be necessary if a user disables a security protection (e.g., host-based firewall) required by policy or when the firewall becomes non-compliant after a firewall patch is issued and network policy is changed to require the patch. A third use of NEA technology may be to verify or supplement organization asset information stored in inventory databases. NEA technology can also be used to check and report compliance for endpoints when they try to access certain mission critical applications within an enterprise, employing service (application) triggered assessment.
(page 10 continued on part 2)