Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5209

Network Endpoint Assessment (NEA): Overview and Requirements

Pages: 53
Informational
Part 1 of 3 – Pages 1 to 10
None   None   Next

Top   ToC   RFC5209 - Page 1
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.
Top   ToC   RFC5209 - Page 2

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
Top   ToC   RFC5209 - Page 3
   7. Requirements ...................................................34
      7.1. Common Protocol Requirements ..............................34
      7.2. Posture Attribute (PA) Protocol Requirements ..............35
      7.3. Posture Broker (PB) Protocol Requirements .................36
      7.4. Posture Transport (PT) Protocol Requirements ..............38
   8. Security Considerations ........................................38
      8.1. Trust .....................................................39
           8.1.1. Endpoint ...........................................40
           8.1.2. Network Communications .............................41
           8.1.3. NEA Server .........................................42
      8.2. Protection Mechanisms at Multiple Layers ..................43
      8.3. Relevant Classes of Attack ................................43
           8.3.1. Man-in-the-Middle (MITM) ...........................44
           8.3.2. Message Modification ...............................45
           8.3.3. Message Replay or Attribute Theft ..................45
           8.3.4. Other Types of Attack ..............................46
   9. Privacy Considerations .........................................46
      9.1. Implementer Considerations ................................47
      9.2. Minimizing Attribute Disclosure ...........................49
   10. References ....................................................50
      10.1. Normative References .....................................50
      10.2. Informative References ...................................50
   11. Acknowledgments ...............................................51

1. 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
Top   ToC   RFC5209 - Page 4
   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.
Top   ToC   RFC5209 - Page 5

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.
Top   ToC   RFC5209 - Page 6
   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.
Top   ToC   RFC5209 - Page 7
   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,
Top   ToC   RFC5209 - Page 8
      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.
Top   ToC   RFC5209 - Page 9
   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.
Top   ToC   RFC5209 - Page 10
   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)

Next Section