tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5209

Informational
Pages: 53
Top     in Index     Prev     Next
in Group Index     No Prev: Lowest Number in Group     Next in Group     Group: NEA

Network Endpoint Assessment (NEA): Overview and Requirements

Part 1 of 3, p. 1 to 10
None       Next RFC Part

 


Top       ToC       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       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       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       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       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       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       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       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       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       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 RFC Part