doc: Add RFC documents

1 files changed, 2971 insertions, 0 deletions

diff --git a/doc/rfc/rfc5209.txt b/doc/rfc/rfc5209.txt
new file mode 100644
index 0000000..ef5d22e
--- /dev/null
+++ b/doc/rfc/rfc5209.txt
@@ -0,0 +1,2971 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sangster, et al.             Informational                      [Page 1]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+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
+
+
+
+
+
+Sangster, et al.             Informational                      [Page 2]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+   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
+
+
+
+Sangster, et al.             Informational                      [Page 3]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+   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.
+
+
+
+Sangster, et al.             Informational                      [Page 4]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+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.
+
+
+
+
+
+
+Sangster, et al.             Informational                      [Page 5]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+   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.
+
+
+
+
+
+
+Sangster, et al.             Informational                      [Page 6]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+   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,
+
+
+
+Sangster, et al.             Informational                      [Page 7]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+      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.
+
+
+
+Sangster, et al.             Informational                      [Page 8]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+   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.
+
+
+
+
+Sangster, et al.             Informational                      [Page 9]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+   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.
+
+5.  Reference Model
+
+   This section describes the reference model for Network Endpoint
+   Assessment.  This model is provided to establish a context for the
+   discussion of requirements and may not directly map to any particular
+   product or deployment architecture.  The model identifies the major
+
+
+
+
+
+Sangster, et al.             Informational                     [Page 10]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+   functionality of the NEA Client and Server and their relationships,
+   as well as the protocols they use to communicate at various levels
+   (e.g., PA is carried by the PB protocol).
+
+   While the diagram shows 3 layered protocols, it is envisioned that PA
+   is likely a thin message wrapper around a set of attributes and that
+   it is batched and encapsulated in PB.  PB is primarily a lightweight
+   message batching protocol, so the protocol stack is mostly the
+   transport (PT).  The vertical lines in the model represent APIs
+   and/or protocols between components within the NEA Client or Server.
+   These interfaces are out of scope for standardization in the NEA WG.
+
+    +-------------+                          +--------------+
+    |  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 Model
+
+   The NEA reference model does not include mechanisms for discovery of
+   NEA Clients and NEA Servers.  It is expected that NEA Clients and NEA
+   Servers are configured with information that allows them to reach
+   each other.  The specific methods of referencing the configuration
+   and establishing the communication channel are out of scope for the
+   NEA reference model and should be covered in the specifications of
+   candidate protocols such as the Posture Transport (PT) protocol.
+
+
+
+
+
+
+Sangster, et al.             Informational                     [Page 11]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+5.1.  NEA Client and Server
+
+5.1.1.  NEA Client
+
+   The NEA Client is resident on an endpoint device and comprised of the
+   following functionality:
+
+      o Posture Collector(s)
+
+      o Posture Broker Client
+
+      o Posture Transport Client(s)
+
+   The NEA Client is responsible for responding to requests for
+   attributes describing the configuration of the local operating domain
+   of the client and handling the assessment results including potential
+   remediation instructions for how to conform to policy.  A NEA Client
+   is not responsible for reporting on the posture of entities that
+   might exist on the endpoint or over the network that are outside the
+   domain of execution (e.g., in other virtual machine domains) of the
+   NEA Client.
+
+   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 lacking NEA Client software (which is out of NEA scope) or
+   choosing not to provide the attributes required by the NEA Server
+   could be considered non-compliant.  The NEA model includes
+   capabilities to enable the endpoint to update its contents in order
+   to become compliant.
+
+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.  The
+   Posture Collector is also responsible for handling assessment
+   decisions in Result Attributes and remediation instructions in
+   Remediation Attributes.  A single NEA Client can have several Posture
+   Collectors capable of collecting standard and/or vendor-specific
+   Posture Attributes for particular features of the endpoint.  Typical
+
+
+
+Sangster, et al.             Informational                     [Page 12]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+   examples include Posture Collectors that provide information about
+   Operating System (OS) version and patch levels, anti-virus software,
+   and security mechanisms on the endpoint such as host-based Intrusion
+   Detection System (IDS) or firewall.
+
+   Each Posture Collector will be associated with one or more
+   identifiers that enable it to be specified as the destination in a PA
+   message.  The Posture Broker Client uses these identifiers to route
+   messages to this Collector.  An identifier might be dynamic (e.g.,
+   generated by the Posture Broker Client at run-time during
+   registration) or more static (e.g., pre-assigned to the Posture
+   Collector at install-time and passed to the Posture Broker Client
+   during registration) or a function of the attribute messages the
+   Collector desires to receive (e.g., message type for subscription).
+
+   The NEA model allocates the following responsibilities to the Posture
+   Collector:
+
+      o Consulting with local privacy and security policies that may
+        restrict what information is allowed to be disclosed to a given
+        NEA Server.
+
+      o 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.
+
+      o Receiving attributes containing remediation instructions on how
+        to update functionality on the endpoint.  This could require the
+        Collector to interact with the user, owner, and/or a remediation
+        server.
+
+      o Monitoring the posture of (a) particular features(s) on the
+        endpoint for posture changes that require notification to the
+        Posture Broker Client.
+
+      o Providing cryptographic verification of the attributes received
+        from the Validator and offering cryptographic protection to the
+        attributes returned.
+
+
+
+
+Sangster, et al.             Informational                     [Page 13]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+   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
+
+   The Posture Broker Client is both a PA message multiplexer and a
+   de-multiplexer.  The Posture Broker Client is responsible for
+   de-multiplexing the PB message received from the NEA Server and
+   distributing each encapsulated PA message to the corresponding
+   Posture Collector(s).  The model also allows for the posture
+   information request to be pre-provisioned on the NEA Client to
+   improve performance by allowing the NEA Client to report posture
+   without receiving a request for particular attributes from the NEA
+   Server.
+
+   The Posture Broker Client also multiplexes the responses from the
+   Posture Collector(s) and returns them to the NEA Server.  The Posture
+   Broker Client constructs one or more PB messages using the PA
+   message(s) it obtains from the Posture Collector(s) involved in the
+   assessment.  The quantity and ordering of Posture Collector responses
+   (PA message(s)) multiplexed into the PB response message(s) can be
+   determined by the Posture Broker Client based on many factors
+   including policy or characteristics of the underlying network
+   transport (e.g., MTU).  A particular NEA Client will have one Posture
+   Broker Client.
+
+   The Posture Broker Client also handles the global assessment decision
+   from the Posture Broker Server and may interact with the user to
+   communicate the global assessment decision and aid in any necessary
+   remediation steps.
+
+   The NEA model allocates the following responsibilities to the Posture
+   Broker Client:
+
+      o Maintaining a registry of known Posture Collectors and allowing
+        for Posture Collectors to dynamically register and deregister.
+
+      o Multiplexing and de-multiplexing attribute messages between the
+        NEA Server and the relevant Posture Collectors.
+
+      o Handling posture change notifications from Posture Collectors
+        and triggering reassessment.
+
+      o Providing user notification about the global assessment decision
+        and other user messages sent by the NEA Server.
+
+
+
+Sangster, et al.             Informational                     [Page 14]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+5.1.1.3.  Posture Transport Client
+
+   The Posture Transport Client is responsible for establishing a
+   reliable communication channel with the NEA Server for the message
+   dialog between the NEA Client and NEA Server.  There might be more
+   than one Posture Transport Client on a particular NEA Client
+   supporting different transport protocols (e.g., 802.1X, VPN).
+   Certain Posture Transport Clients may be configured with the address
+   of the appropriate Posture Transport Server to use for a particular
+   network.
+
+   The NEA model allocates the following responsibilities to the Posture
+   Transport Client:
+
+      o  Initiating and maintaining the communication channel to the NEA
+         Server.  The Posture Transport Client hides the details of the
+         underlying carrier that could be a Layer 2 or Layer 3 protocol.
+
+      o  Providing cryptographic protection for the message dialog
+         between the NEA Client and NEA Server.
+
+5.1.2.  NEA Server
+
+   The NEA Server is typically comprised of the following NEA
+   functionality:
+
+      o Posture Validator(s)
+
+      o Posture Broker Server
+
+      o Posture Transport Server(s)
+
+   The Posture Validators might be located on a separate server from the
+   Posture Broker Server, requiring the Posture Broker Server to deal
+   with both local and remote Posture Validators.
+
+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.
+
+
+
+
+
+Sangster, et al.             Informational                     [Page 15]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+   Each Posture Validator will be associated with one or more
+   identifiers that enable it to be specified as the destination in a PA
+   message.  The Posture Broker Server uses this identifier to route
+   messages to this Validator.  This identifier might be dynamic (e.g.,
+   generated by the Posture Broker Server at run-time during
+   registration) or more static (e.g., pre-assigned to a Posture
+   Validator at install-time and passed to the Posture Broker Server
+   during registration) or a function of the attribute messages the
+   Validator desires to receive (e.g., message type for subscription).
+
+   Posture Validators can be co-located on the NEA Server or can be
+   hosted on separate servers.  A particular NEA Server is likely to
+   need to handle multiple Posture Validators.
+
+   The NEA model allocates the following responsibilities to the Posture
+   Validator:
+
+      o Requesting attributes from a Posture Collector.  The request may
+        include:
+
+         - Request Attributes that indicate to the Posture Collector to
+           fetch and provide Posture Attributes for particular
+           functionality on the endpoint.
+
+      o Receiving attributes from the Posture Collector.  The response
+        from the Posture Collector may include:
+
+         - Posture Attributes collected for the requested functionality.
+
+         - Assertion Attributes that indicate the compliance result from
+           a prior assessment.
+
+      o Assessing the posture of endpoint features based on the
+        attributes received from the Collector.
+
+      o Communicating the posture assessment result to the Posture
+        Broker Server.
+
+      o 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.
+
+      o Monitoring out-of-band updates that trigger reassessment and
+        require notifications to be sent to the Posture Broker Server.
+
+
+
+Sangster, et al.             Informational                     [Page 16]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+      o Providing cryptographic protection for attributes sent to the
+        Posture Collector and offering cryptographic verification of the
+        attributes received from the Posture Collector.
+
+   The above list describes the model's view of the possible
+   responsibilities of the Posture Validator.  Note that this is not a
+   set of requirements for what each Posture Validator implementation
+   must support, nor is it an exhaustive list of all the things a
+   Posture Validator may do.
+
+5.1.2.2.  Posture Broker Server
+
+   The Posture Broker Server acts as a multiplexer and a de-multiplexer
+   for attribute messages.  The Posture Broker Server parses the PB
+   messages received from the NEA Client and de-multiplexes them into PA
+   messages that it passes to the associated Posture Validators.  The
+   Posture Broker Server multiplexes the PA messages (e.g., messages
+   containing (a) Request Attribute(s) from the relevant Posture
+   Validator(s)) into one or more PB messages and sends them to the NEA
+   Client via the Posture Transport protocol.  The quantity and ordering
+   of Posture Validator responses (PA messages) and global assessment
+   decision multiplexed into the PB response message(s) can be
+   determined by the Posture Broker Server based on many factors
+   including policy or characteristics of the underlying network
+   transport (e.g., MTU).
+
+   The Posture Broker Server is also responsible for computing the
+   global assessment decision based on individual posture assessment
+   results from the various Posture Validators.  This global assessment
+   decision is sent back to the NEA Client in Result Attributes within a
+   PB message.  A particular NEA Server will have one Posture Broker
+   Server, and this Posture Broker Server will handle all the local and
+   remote Posture Validators.
+
+   The NEA model allocates the following responsibilities to the Posture
+   Broker Server:
+
+      o Maintaining a registry of Posture Validators and allowing for
+        Posture Validators to register and deregister.
+
+      o Multiplexing and de-multiplexing posture messages from and to
+        the relevant Posture Validators.
+
+      o Computing the global assessment decision based on posture
+        assessment results from the various Posture Validators and
+        compliance policy.  This assessment decision is sent to the
+        Posture Broker Client in a PB message.
+
+
+
+
+Sangster, et al.             Informational                     [Page 17]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+5.1.2.3.  Posture Transport Server
+
+   The Posture Transport Server is responsible for establishing a
+   reliable communication channel with the NEA Client for the message
+   dialog between the NEA Client and NEA Server.  There might be more
+   than one Posture Transport Server on a particular NEA Server to
+   support different transport protocols.  A particular Posture
+   Transport Server will typically handle requests from several Posture
+   Transport Clients and may require local configuration describing how
+   to reach the NEA Clients.
+
+   The NEA model allocates the following responsibilities to the Posture
+   Transport Server:
+
+      o Initiating and maintaining a communication channel with,
+        potentially, several NEA Clients.
+
+      o 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 for the exchange of attributes across the network.
+   While these protocols are intended to be used together to fulfill a
+   particular role in the model, they may offer overlapping
+   functionality.  For example, each protocol should be capable of
+   protecting its information from attack (see section 8.2 for more
+   information).
+
+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.  The PA protocol
+   is a message-oriented lightweight wrapper around a set of attributes
+   being exchanged.  This wrapper may indicate the purpose of attributes
+   within the message.  Some of the types of messages expected include:
+   requests for posture information (Request Attributes), posture
+   information about the endpoint (Posture Attributes), results of an
+   assessment (Result Attributes), reusable compliance assertions
+   (Assertion Attributes), and instructions to remediate non-compliant
+   portions of the endpoint (Remediation Attributes).  The PA protocol
+   also provides the requisite encoding and cryptographic protection for
+   the Posture Attributes.
+
+
+
+
+
+
+
+Sangster, et al.             Informational                     [Page 18]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+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 allowing for message
+   dialogs for every assessment.  This PB session is then used to bind
+   multiple Posture Attribute requests and responses from the different
+   Posture Collectors and Posture Validators involved in a particular
+   assessment.  The PB protocol may also carry the global assessment
+   decision in the Result Attribute from the Posture Broker Server to
+   the Posture Broker Client.  PB may be used to carry additional types
+   of messages for use by the Posture Broker Client and Server (e.g.,
+   information about user preferred interface settings such as
+   language).
+
+5.2.3.  Posture Transport Protocol (PT)
+
+   PT is a transport protocol between the NEA Client and the NEA Server
+   responsible for carrying the messages generated by the PB protocol.
+   The PT protocol(s) transport(s) PB messages during the network
+   connection request or after network connectivity has been
+   established.
+
+   In scenarios where an initial assessment needs to occur during the
+   network connection, the PT protocol (e.g., EAP within 802.1X) may
+   have constrained use of the network, so deployments may choose to
+   limit the amount and/or size of the attributes exchanged.  The NEA
+   Client and NEA Server should be able to detect when a potentially
+   constrained situation exists prior to the assessment based upon
+   properties of the underlying network protocol.  Using this
+   information, NEA policy could dictate what aspects of the endpoint to
+   include in the initial assessment and potentially limit the PA
+   message attributes exchanged.  This could be followed up by a full
+   reassessment after the endpoint is placed on the network.
+   Alternatively, deployments can choose not to limit their assessment
+   by configuring their network access technology to temporarily grant
+   restricted IP connectivity prior to the assessment and use an
+   unconstrained, high bandwidth IP-based transport during the
+   assessment.  Some of the constraints that may exist for protocols
+   involved in the network connection phase include:
+
+      o Limited maximum transmission unit (MTU) size and ability to
+        negotiate larger MTUs,
+
+      o Inability to perform multiple roundtrips,
+
+      o Lack of support for piggybacking attributes for other protocols,
+
+
+
+Sangster, et al.             Informational                     [Page 19]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+      o Low bandwidth or high latency limitations precluding exchanges
+        of large amounts of data,
+
+      o Inability of servers to initiate messages except during the
+        network connection phase.
+
+   The PT protocol selection process needs to consider the impact of
+   selecting a particular PT and set of underlying protocols on the
+   deployment needs of PA and PB.  PA and PB will be selected prior to
+   PT so the needs of PA and PB will be known.  Certain underlying
+   protocol stacks may be too constrained to support adequate NEA
+   assessments during network connection.
+
+   The PT protocol provides reliable message delivery, mutual
+   authentication, and cryptographic protection for the PB messages as
+   specified by local policy.
+
+5.3.  Attributes
+
+   The PA protocol is responsible for the exchange of attributes between
+   a Posture Collector and Posture Validator.  The PB protocol may also
+   carry the global assessment decision attributes from the Posture
+   Broker Server.  Attributes are effectively the reserved word 'nouns'
+   of the posture assessment.  The NEA Server is only able to ask for
+   information that has a corresponding attribute, thus bounding what
+   type of posture can be obtained.  The NEA WG will define a common
+   (standard) set of attributes that are expected to be widely
+   applicable to Posture Collectors and thus used for maximum
+   interoperability, but Posture Collectors may support additional
+   vendor-specific attributes when necessary.
+
+   Depending on the deployment scenario, the purpose of the attributes
+   exchanged may be different (e.g., posture information vs. asserted
+   compliance).  This section discusses the originator and expected
+   situation resulting in the use of each classification of attributes
+   in a PA message.  These classifications are not intended to dictate
+   how the NEA WG will specify the attributes when defining the
+   attribute namespace or schema.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sangster, et al.             Informational                     [Page 20]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+5.3.1.  Attributes Normally Sent by NEA Client:
+
+      o Posture Attributes - Attributes and values sent to report
+        information about a particular aspect (based on semantic of the
+        attribute) of the system.  These attributes are typically sent
+        in response to Request Attributes from the NEA Server.  For
+        example, a set of Posture Attributes might describe the status
+        of the host-based firewall (e.g., if running, vendor, version).
+        The NEA Server would base its decision on comparing this type of
+        attribute against policy.
+
+      o 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:
+
+      o Request Attributes - Attributes that define the specific posture
+        information desired by the NEA Server.  These attributes might
+        effectively form a template that the Posture Collector fills in
+        (subject to local policy restrictions) with the specific value
+        corresponding to each attribute.  The resulting attributes are
+        typically Posture or Assertion Attributes from the NEA Client.
+
+      o Result Attributes - Attributes that contain the decisions of the
+        Posture Validators and/or Posture Broker Server.  The level of
+        detail provided may vary from which individual attributes were
+        compliant or not through just the global assessment decision.
+
+      o Remediation Attributes - Attributes that explain to the NEA
+        Client and its user how to update the endpoint to become
+        compliant with the NEA Server policies.  These attributes are
+        sent when the global assessment decision was that the endpoint
+        is not currently compliant.  Remediation and Result Attributes
+        may both exist within a NEA Server attribute message.
+
+      o 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.
+
+
+
+
+
+
+Sangster, et al.             Informational                     [Page 21]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+6.  Use Cases
+
+   This section discusses several of the NEA use cases with intent to
+   describe and collectively bound the NEA problem space under
+   consideration.  The use cases provide a context and general rationale
+   for the defined requirements.  In order to ease understanding of each
+   use case and how it maps to the reference model, each use case will
+   be accompanied by a simple example and a discussion of how this
+   example relates to the NEA protocols.  It should be emphasized that
+   the provided examples are not intended to indicate the only approach
+   to addressing the use case but rather are included to ease
+   understanding of how the flows might occur and impact the NEA
+   protocols.
+
+   We broadly classify the use cases into two categories, each with its
+   own set of trigger events:
+
+      o Initial assessment - evaluation of the posture of an endpoint
+        that has not recently been assessed and thus is not in
+        possession of any valid proof that it should be considered
+        compliant.  This evaluation might be triggered by a request to
+        join a network, a request to use a service, or a desire to
+        understand the posture of a system.
+
+      o 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 occurs when a NEA Client or Server event occurs
+   that causes the evaluation of the posture of the endpoint for the
+   first time.  Endpoints do not qualify for this category of use case
+   if they have been recently assessed and the NEA Client or Server has
+   maintained state (or proof) that the endpoint is compliant and
+   therefore does not need to have its posture evaluated again.
+
+6.1.1.  Triggered by Network Connection or Service Request
+
+   This use case focuses on assessments performed at the time an
+   endpoint attempts to join a network or request use of a service that
+   requires a posture evaluation.  This use case is particularly
+   interesting because it allows the NEA Server to evaluate the posture
+   of an endpoint before allowing it access to the network or service.
+
+
+
+
+Sangster, et al.             Informational                     [Page 22]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+   This approach could be used to help detect endpoints with known
+   vulnerabilities and facilitate their repair before they are admitted
+   to the network and potentially exposed to threats on the network.
+
+   A variety of types of endpoint actions could result in this class of
+   assessment.  For example, an assessment could be triggered by the
+   endpoint trying to access a highly protected network service (e.g.,
+   financial or HR application server) where heightened security
+   checking is required.  A better known example could include
+   requesting entrance to a network that requires systems to meet
+   compliance policy.  This example is discussed in more detail in the
+   following section.
+
+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
+
+   The following describes typical message flows through the NEA
+   reference model for this example use case:
+
+      1. The IT employee's desktop computer connects to the network
+         through an access gateway in the wired enterprise network.
+
+      2. The Posture Broker Server on the NEA Server is instructed to
+         assess the endpoint joining the wired network.
+
+      3. Based upon compliance policy, the Posture Broker Server
+         contacts the operating system patch, host-based firewall, and
+         anti-virus Posture Validators to request the necessary posture.
+         Each Posture Validator creates a PA message containing the
+         desired attributes to be requested for assessment from the
+         desktop system.
+
+
+
+
+
+Sangster, et al.             Informational                     [Page 23]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+      4. The Posture Broker Server aggregates the PA messages from the
+         Posture Validators into a PB message.  The Posture Broker
+         Server passes the PB message to the Posture Transport Server
+         that uses the PT protocol to send the PB message to the NEA
+         Client on the desktop computer.
+
+      5. The Posture Transport Client receives the message from the NEA
+         Server and passes it to the Posture Broker Client for message
+         delivery.
+
+      6. The Posture Broker Client de-multiplexes the PB message and
+         delivers the PA messages with the requests for attributes to
+         the firewall, operating system patch, and anti-virus Posture
+         Collectors.
+
+      7. Each Posture Collector involved consults local privacy policy
+         to determine what information is allowed to be disclosed and
+         then returns the requested attributes that are authorized in a
+         PA message to the Posture Broker Client.
+
+      8. The Posture Broker Client aggregates these PA messages into a
+         single PB message and sends it to the Posture Broker Server
+         using the Posture Transport Client to Server session.
+
+      9. The Posture Transport Server provides the PB message to the
+         Posture Broker Server that de-multiplexes the message and sends
+         the appropriate attributes to the corresponding Posture
+         Validator.
+
+     10. Each Posture Validator compares the values of the attributes it
+         receives with the expected values defined in its policy.
+
+     11. The anti-virus and firewall Posture Validators return
+         attributes to the Posture Broker Server stating the desktop
+         computer is compliant, but the operating system patch Posture
+         Validator returns non-compliant.  The operating system patch
+         Posture Validator creates a PA message that contains attributes
+         with remediation instructions in addition to the attribute
+         indicating non-compliance result.
+
+     12. The Posture Broker Server aggregates the PA messages and sends
+         them in a PB message to the Posture Broker Client via the
+         Posture Transport Server and Posture Transport Client.
+
+
+
+
+
+
+
+
+Sangster, et al.             Informational                     [Page 24]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+     13. The Posture Broker Client delivers the PA messages with the
+         results from the various Posture Validators to the Posture
+         Collectors including the PA message containing attributes with
+         remediation instructions to the operating system patch Posture
+         Collector.  This Posture Collector then interacts with the user
+         to download and install the needed patches, potentially while
+         the endpoint remains quarantined.
+
+     14. Upon completion of the remediation, the above steps 1-10 are
+         repeated (triggered by the NEA Client repeating its request to
+         join the network).
+
+     15. This time each involved Posture Validator (including the
+         operating system patch Posture Validator) returns a compliant
+         status and the Posture Broker Server returns a compliant result
+         indicating a global success.
+
+     16. The Posture Broker Client receives the compliant result and the
+         IT employee's desktop is now on the network.
+
+6.1.1.3.  Impact on Requirements
+
+   The following are several different aspects of the use case example
+   that potentially need to be factored into the requirements.
+
+      o Posture assessment before endpoint allowed on network
+
+      o Endpoint sends attributes containing posture information
+
+      o NEA Server sends remediation instructions
+
+      o NEA Client causes a reassessment after remediation
+
+6.1.2.  Triggered by Endpoint
+
+   This use case highlights that an endpoint (possibly at the request of
+   a user) may wish to trigger an assessment of its posture to determine
+   whether its security protective mechanisms are running and up to
+   date.
+
+6.1.2.1.  Example
+
+   A student goes to the terminal room to work on a project.  The
+   terminal room contains shared systems owned by the school that are on
+   the network.  These systems have been previously used by other
+   students so their security posture is unknown.  The student wishes to
+   check whether a system is currently in compliance with the school's
+   security policies prior to doing work, so she requests a posture
+
+
+
+Sangster, et al.             Informational                     [Page 25]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+   assessment.  The NEA Server performs an initial assessment of the
+   system and determines it is compliant but the anti-virus protection
+   is not in use.  The student receives an advisory response indicating
+   the system's anti-virus software is turned off but that otherwise it
+   complies with the school's policy.  The student turns on the
+   anti-virus software, initiates a scan, and upon completion decides to
+   trust the system with her work.
+
+6.1.2.2.  Possible Flows and Protocol Usage
+
+   The following describes the message flows through the NEA reference
+   model for the student using a terminal room shared system example:
+
+      1. Student triggers the Posture Broker Client on the computer
+         system in the terminal room to initiate a posture assessment.
+
+      2. The Posture Broker Client establishes a session with the
+         Posture Broker Server that causes an assessment to be
+         triggered.
+
+      3. The Posture Broker Server detects the new session and consults
+         policy to determine that Posture Validators to involve in the
+         assessment.  The Posture Broker Server decides to employ
+         several Posture Validators including the anti-virus Posture
+         Validator.
+
+      4. The Posture Validators involved create PA messages containing
+         requests for particular attributes containing information about
+         the desired terminal room computer based on the school's
+         security policy.
+
+      5. The Posture Broker Server assembles a PB message including each
+         of the PA messages from the Posture Validators.
+
+      6. The Posture Transport Server sends the PB message to the
+         Posture Transport Client where it is passed on to the Posture
+         Broker Client.
+
+      7. The Posture Broker Client on the student's computer
+         de-multiplexes the PA messages and delivers them to the
+         corresponding Posture Collectors.
+
+      8. The Posture Collectors consult privacy policy to decide what
+         information to share with the Server.  If allowable, the
+         Collectors each return a PA message containing the requested
+         posture to the Posture Broker Client.
+
+
+
+
+
+Sangster, et al.             Informational                     [Page 26]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+      9. The Posture Broker Client aggregates the returned PA messages
+         into a PB message and hands it to the Posture Transport Client
+         for transmission to the Posture Transport Server.
+
+     10. The Posture Broker Server separates and distributes the Posture
+         Collector PA messages to the associated Posture Validators.
+
+     11. The Posture Validators determine whether the attributes
+         containing the posture included in the PA message are compliant
+         with their policies and returns a posture assessment decision
+         to the Posture Broker Server.  In this case, the anti-virus
+         Posture Validator returns a PA message indicating a
+         non-compliant result because the anti-virus software is not
+         running and includes attributes describing how to activate the
+         software.
+
+     12. The Posture Broker Server determines the overall compliance
+         decision based on all of the Validators' assessment results and
+         sends a PB message containing an attribute expressing the
+         global assessment decision and the anti-virus Validator's PA
+         message.  In this case, the global assessment decision
+         indicates the system is compliant (despite the anti-virus
+         Validator's result) because the Posture Broker Server policy
+         allowed for the anti-virus to not be running as long as the
+         system was properly patched and running a firewall (which was
+         the case according to the other Posture Validators).
+
+     13. The Posture Transport Server sends the PB message to the
+         Posture Transport Client that provides the message to the
+         Posture Broker Client.
+
+     14. The Posture Broker Client on the terminal room computer
+         examines the PB message's global assessment decision attribute
+         and reports to the student that the system was deemed to be
+         compliant, but that an advisory was included.
+
+     15. The Posture Broker Client provides the PA message with the
+         remediation attributes to the anti-virus Posture Collector that
+         interacts with the user to explain how to turn on anti-virus to
+         improve the local protections.
+
+     16. The student turns on the anti-virus software and on completion
+         steps 1-10 are repeated.
+
+     17. This time the anti-virus Posture Validator returns a success
+         status and the Posture Broker Server returns a successful
+         global assessment decision in the PB message.
+
+
+
+
+Sangster, et al.             Informational                     [Page 27]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+     18. The Posture Broker Client receives the successful global
+         assessment decision in the PB message and the student now uses
+         the computer for her assignment.
+
+6.1.2.3.  Impact on Requirements
+
+   The following are several different aspects of the use case example
+   that potentially need to be factored into the requirements.
+
+      o Voluntary endpoint requested initial assessment,
+
+      o 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
+
+   Reassessment(s) of endpoints can happen anytime after being admitted
+   to the network after a successful initial NEA assessment.  These
+   reassessments may be event-based, such as driven by posture changes
+   detected by the NEA Client, or changes detected by network
+   infrastructure such as detection of suspicious behavior or network
+   policy updates on the NEA Server.  They may also be periodic (timer-
+   driven) to reassess the health of the endpoint.
+
+6.2.1.  Triggered by NEA Client
+
+   This use case allows for software on the endpoint or a user to
+   determine that a reassessment of the system is required.  There are a
+   variety of reasons why such a reassessment might be beneficial
+   including: changes in its previously reported posture, detection of
+   potentially suspicious behavior, or even to enable the system to
+   periodically poll the NEA Server to assess its condition relative to
+   the latest policies.
+
+6.2.1.1.  Example
+
+   The desktops within a company's HR department have a history of poor
+   security practices and eventual compromise.  The HR department
+   administrator decides to deploy software on each desktop to monitor
+   the use of security protective mechanisms to assure their use.  One
+   day, an HR person accidentally turns off the desktop firewall.  The
+   monitoring process detects the lack of a firewall and contacts the
+   NEA Server to request a reassessment of the firewall compliance.  The
+   NEA Server returns a decision that the firewall must be reactivated
+   to stay on the network.  The NEA Client explains the decision to the
+   user and how to reactivate the firewall.  The HR person restarts the
+   firewall and initiates a request to rejoin the network.
+
+
+
+Sangster, et al.             Informational                     [Page 28]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+6.2.1.2.  Possible Flows & Protocol Usage
+
+   The following describes the message flows through the NEA reference
+   model for the HR department example:
+
+      1. The desktop monitoring software that typically might act as a
+         Posture Collector triggers the Posture Broker Client to
+         initiate a posture reassessment.  The Posture Broker Client
+         creates a PB message that contains a PA message indicating the
+         desktop firewall has been disabled.
+
+      2. The Posture Broker Client sends the PB message to the Posture
+         Broker Server.
+
+      3. The Posture Transport Client sends the PB message to the
+         Posture Transport Server over the PT protocol.
+
+      4. The Posture Broker Server receives the PB message and forwards
+         the PA message to the firewall Posture Validator for
+         evaluation.
+
+      5. The firewall Posture Validator determines that the endpoint is
+         no longer compliant because its firewall has been disabled.
+
+      6. The Posture Validator generates a PA message that contains
+         attributes indicating a non-compliant posture assessment result
+         and remediation instructions for how to reactivate the
+         firewall.
+
+      7. The Posture Validator communicates the PA message with the
+         posture assessment result to the Posture Broker Server to
+         respond back to the NEA Client.
+
+      8. The Posture Broker Server generates a PB message including a
+         global assessment decision of non-compliant and the PA message
+         from the firewall Posture Validator.
+
+      9. The Posture Transport Server transports the PB message to the
+         Posture Transport Client where it is passed to the Posture
+         Broker Client.
+
+     10. The Posture Broker Client processes the attribute containing
+         the global assessment decision received from the NEA Server and
+         displays the non-compliance messages to the user.
+
+
+
+
+
+
+
+Sangster, et al.             Informational                     [Page 29]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+     11. The Posture Broker Client forwards the PA message to the
+         firewall Posture Collector; the Posture Collector displays the
+         remediation instructions for how to enable the desktop
+         firewall.
+
+     12. The user is prompted to initiate a reassessment after
+         completing the remediation.
+
+     13. Upon completion of the remediation, the NEA Client reinitiates
+         a request for reassessment and steps 1-4 are repeated.  This
+         time the firewall Posture Validator determines the endpoint is
+         compliant and returns a successful posture assessment decision.
+
+     14. The Posture Broker Server generates a PB message with a global
+         assessment decision of compliant and returns this to the NEA
+         Client.
+
+6.2.1.3.  Impact on Requirements
+
+   The following are several different aspects of the use case example
+   that potentially need to be factored into the requirements.
+
+      o Voluntary, endpoint (software) initiated posture reassessment
+        request
+
+      o NEA Server requests specific firewall-oriented Posture
+        Attributes
+
+      o NEA Client (firewall Posture Collector) interacts with user to
+        remediate problem
+
+6.2.2.  Triggered by NEA Server
+
+   In many cases, especially for reassessment, the NEA Server may
+   initiate specific or complete reassessment of one or more endpoints
+   triggered by:
+
+      o Time (periodic)
+      o Event occurrence
+      o Policy updates
+
+6.2.2.1.  Example
+
+   An enterprise requires employees on the network to always stay up to
+   date with security critical operating system patches.  A marketing
+   employee joins the network and performs an initial assessment.  The
+   assessment determines the employee's laptop is compliant.  Several
+
+
+
+
+Sangster, et al.             Informational                     [Page 30]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+   hours later, a major operating system vendor releases a set of
+   patches preventing a serious vulnerability that is being exploited on
+   the Internet.
+
+   The enterprise administrators make available the patches and change
+   the network policy to require them to be installed by 5 PM.  This
+   policy change causes the NEA Server to request a reassessment to
+   determine which endpoints are impacted and lacking the patches.  The
+   marketing employee's laptop is reassessed and determined to need the
+   patches.  A remediation advisory is sent and presented to the
+   employee explaining how to obtain the patches and that they must be
+   installed by 5 PM.  The marketing employee immediately downloads and
+   installs the patches and obtains an assertion that all patches are
+   now installed.
+
+   At 5 PM, the enterprise performs another reassessment of all impacted
+   endpoints to determine if they are now in compliance.  The marketing
+   employee's laptop is reassessed and presents the assertion that it
+   has the patches installed and thus is determined to be compliant.
+
+6.2.2.2.  Possible Flows and Protocol Usage
+
+   The following describes the message flows through the NEA reference
+   model for the above example:
+
+      1. Marketing employee joins network and completes an initial
+         assessment resulting in a compliant decision.
+
+      2. The Enterprise Administrator configures an operating system
+         patch policy indicating that recent patches are required on all
+         endpoints by 5 PM to prevent serious vulnerabilities.
+
+      3. The NEA Server's operating system patch Posture Validator
+         becomes aware of this policy change and creates a PA message
+         requesting attributes describing OS patches in use and triggers
+         the Posture Broker Server to initiate a posture reassessment of
+         all endpoints connected to the network.
+
+      4. The Posture Broker creates a PB message that includes the PA
+         message from the operating system patch Posture Validator.
+
+      5. The Posture Broker Server gradually establishes a session with
+         each available NEA Client.
+
+      6. The Posture Broker Server sends the PB message to the Posture
+         Broker Client.
+
+
+
+
+
+Sangster, et al.             Informational                     [Page 31]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+      7. The Posture Transport Server carries the PB message to the
+         Posture Transport Client over the PT protocol.
+
+      8. The Posture Broker Client receives the PB message and forwards
+         the PA message to the operating system patch Posture Collector.
+
+      9. The operating system patch Posture Collector determines the OS
+         patches present on the endpoint and if authorized by its
+         disclosure policy creates a PA message containing the patch
+         information attributes.
+
+     10. The Posture Broker Client sends a PB message that includes the
+         operating system patch PA message.
+
+     11. The Posture Transport Client transports the PB message to the
+         Posture Transport Server where it is passed to the Posture
+         Broker Server.
+
+     12. The Posture Broker Server receives the PB message and delivers
+         the PA message to the operating system patch Posture Validator.
+
+     13. The operating system patch Posture Validator extracts the
+         attributes describing the current OS patches from the PA
+         message and uses the values to determine whether the endpoint
+         is compliant with the new policy.  The Posture Validator
+         determines that the endpoint is not compliant since it does not
+         have the new OS patches installed.
+
+     14. The Posture Validator generates a PA message that includes
+         attributes stating the posture assessment decision is
+         non-compliant and attributes containing the remediation
+         instructions to enable the endpoint to download the required OS
+         patches.
+
+     15. The Posture Validator communicates the posture assessment
+         result to the Posture Broker Server along with its PA message.
+
+     16. The Posture Broker Server generates a global assessment
+         decision and sends a PB message with the decision and the
+         operating system patch Posture Validator's PA message.
+
+     17. The Posture Transport Server transports the PB message to the
+         Posture Transport Client where it is passed to the Posture
+         Broker Client.
+
+     18. The Posture Broker Client processes the Result Attribute
+         received from the NEA Server and displays the non-compliance
+         decision to the user.
+
+
+
+Sangster, et al.             Informational                     [Page 32]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+     19. The Posture Broker Client forwards the PA message containing
+         the remediation instructions to the operating system patch
+         Posture Collector; the Posture Collector guides the user with
+         instructions on how to become compliant that include
+         downloading the appropriate OS patches to prevent the
+         vulnerability.
+
+     20. The marketing employee installs the required patches and now is
+         in compliance.
+
+     21. The NEA Client triggers a reassessment of the operating system
+         patches that causes a repeat of many of the steps above.  This
+         time, in step 13 the operating system patch Posture Validator
+         determines the marketing employee's laptop is compliant.  It
+         returns a reusable (e.g., signed and dated) set of attributes
+         that assert OS patch compliance to the latest policy.  These OS
+         patch compliance assertions can be used in a future PA message
+         from the operating system patch Collector instead of
+         determining and providing the specific patch set posture as
+         before.
+
+     22. This time when the operating system patch Posture Collector
+         receives the PA message that contains reusable attributes
+         asserting compliance, it caches those attributes for future
+         use.
+
+     23. Later at 5 PM, the NEA Server triggers a gradual reassessment
+         to determine compliance to the patch advisory.  When the
+         operating system patch Posture Collector receives the request
+         for posture information (like in step 9 above) it returns the
+         cached set of assertions (instead of specific OS patch
+         information) to indicate that the patches have been installed
+         instead of determining all the patches that have been installed
+         on the system.
+
+     24. When the operating system patch Posture Validator receives the
+         PA message containing the assertions, it is able to determine
+         that they are authentic and acceptable assertions instead of
+         specific posture.  It returns a posture assessment decision of
+         compliant thus allowing the laptop to remain on the network.
+
+6.2.2.3.  Impact on Requirements
+
+   The following are several different aspects of the use case example
+   that potentially need to be factored into the requirements.
+
+      o Server-initiated reassessment required due to urgent patch
+        availability
+
+
+
+Sangster, et al.             Informational                     [Page 33]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+      o NEA Client submits reusable assertion attributes instead of
+        posture that patch is installed
+
+      o NEA Server capable of recognizing previously issued assertion
+        attributes are sufficient instead of posture
+
+7.  Requirements
+
+   This section describes the requirements that will be used by the NEA
+   WG to assess and compare candidate protocols for PA, PB, and PT.
+   These requirements frequently express features that a candidate
+   protocol must be capable of offering so that a deployer can decide
+   whether to make use of that feature.  This section does not state
+   requirements about what features of each protocol must be used during
+   a deployment.
+
+   For example, a requirement (MUST, SHOULD, or MAY) might exist for
+   cryptographic security protections to be available from each protocol
+   but this does not require that a deployer make use of all or even any
+   of them should they deem their environment to offer other protections
+   that are sufficient.
+
+7.1.  Common Protocol Requirements
+
+   The following are the common requirements that apply to the PA, PB,
+   and PT protocols in the NEA reference model:
+
+   C-1  NEA protocols MUST support multiple round trips between the NEA
+        Client and NEA Server in a single assessment.
+
+   C-2  NEA protocols SHOULD provide a way for both the NEA Client and
+        the NEA Server to initiate a posture assessment or reassessment
+        as needed.
+
+   C-3  NEA protocols including security capabilities MUST be capable of
+        protecting against active and passive attacks by intermediaries
+        and endpoints including prevention from replay based attacks.
+
+   C-4  The PA and PB protocols MUST be capable of operating over any PT
+        protocol.  For example, the PB protocol must provide a transport
+        independent interface allowing the PA protocol to operate
+        without change across a variety of network protocol environments
+        (e.g., EAP/802.1X, TLS, and Internet Key Exchange Protocol
+        version 2 (IKEv2)).
+
+
+
+
+
+
+
+Sangster, et al.             Informational                     [Page 34]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+   C-5  The selection process for NEA protocols MUST evaluate and prefer
+        the reuse of existing open standards that meet the requirements
+        before defining new ones.  The goal of NEA is not to create
+        additional alternative protocols where acceptable solutions
+        already exist.
+
+   C-6  NEA protocols MUST be highly scalable; the protocols MUST
+        support many Posture Collectors on a large number of NEA Clients
+        to be assessed by numerous Posture Validators residing on
+        multiple NEA Servers.
+
+   C-7  The protocols MUST support efficient transport of a large number
+        of attribute messages between the NEA Client and the NEA Server.
+
+   C-8  NEA protocols MUST operate efficiently over low bandwidth or
+        high latency links.
+
+   C-9  For any strings intended for display to a user, the protocols
+        MUST support adapting these strings to the user's language
+        preferences.
+
+   C-10 NEA protocols MUST support encoding of strings in UTF-8 format
+        [UTF8].
+
+   C-11 Due to the potentially different transport characteristics
+        provided by the underlying candidate PT protocols, the NEA
+        Client and NEA Server MUST be capable of becoming aware of and
+        adapting to the limitations of the available PT protocol.  For
+        example, some PT protocol characteristics that might impact the
+        operation of PA and PB include restrictions on: which end can
+        initiate a NEA connection, maximum data size in a message or
+        full assessment, upper bound on number of roundtrips, and
+        ordering (duplex) of messages exchanged.  The selection process
+        for the PT protocols MUST consider the limitations the candidate
+        PT protocol would impose upon the PA and PB protocols.
+
+7.2.  Posture Attribute (PA) Protocol Requirements
+
+   The Posture Attribute (PA) protocol defines the transport and data
+   model to carry posture and validation information between a
+   particular Posture Collector associated with the NEA Client and a
+   Posture Validator associated with a NEA Server.  The PA protocol
+   carries collections of standard attributes and vendor-specific
+   attributes.  The PA protocol itself is carried inside the PB
+   protocol.
+
+
+
+
+
+
+Sangster, et al.             Informational                     [Page 35]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+   The following requirements define the desired properties that form
+   the basis for comparison and evaluation of candidate PA protocols.
+   These requirements do not mandate the use of these properties, but
+   merely that the candidate protocols are capable of offering the
+   property if it should be needed.
+
+   PA-1 The PA protocol MUST support communication of an extensible set
+        of NEA standards defined attributes.  These attributes will be
+        distinguishable from non-standard attributes.
+
+   PA-2 The PA protocol MUST support communication of an extensible set
+        of vendor-specific attributes.  These attributes will be
+        segmented into uniquely identified vendor-specific namespaces.
+
+   PA-3 The PA protocol MUST enable a Posture Validator to make one or
+        more requests for attributes from a Posture Collector within a
+        single assessment.  This enables the Posture Validator to
+        reassess the posture of a particular endpoint feature or to
+        request additional posture including from other parts of the
+        endpoint.
+
+   PA-4 The PA protocol MUST be capable of returning attributes from a
+        Posture Validator to a Posture Collector.  For example, this
+        might enable the Posture Collector to learn the specific reason
+        for a failed assessment and to aid in remediation and
+        notification of the system owner.
+
+   PA-5 The PA protocol SHOULD provide authentication, integrity, and
+        confidentiality protection for attributes communicated between a
+        Posture Collector and Posture Validator.  This enables
+        end-to-end security across a NEA deployment that might involve
+        traversal of several systems or trust boundaries.
+
+   PA-6 The 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.
+
+
+
+
+
+Sangster, et al.             Informational                     [Page 36]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+   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-1 The PB protocol MUST be capable of carrying attributes from the
+        Posture Broker Server to the Posture Broker Client.  This
+        enables the Posture Broker Client to learn the posture
+        assessment decision and if appropriate to aid in remediation and
+        notification of the endpoint owner.
+
+   PB-2 The PB protocol MUST NOT interpret the contents of PA messages
+        being carried, i.e., the data it is carrying must be opaque to
+        it.
+
+   PB-3 The PB protocol MUST carry unique identifiers that are used by
+        the Posture Brokers to route (deliver) PA messages between
+        Posture Collectors and Posture Validators.  Such message routing
+        should facilitate dynamic registration or deregistration of
+        Posture Collectors and Validators.  For example, a dynamically
+        registered anti-virus Posture Validator should be able to
+        subscribe to receive messages from its respective anti-virus
+        Posture Collector on NEA Clients.
+
+   PB-4 The PB protocol MUST be capable of supporting a half-duplex PT
+        protocol.  However this does not preclude PB from operating
+        full-duplex when running over a full-duplex PT.
+
+   PB-5 The PB protocol MAY support authentication, integrity and
+        confidentiality protection for the attribute messages it carries
+        between a Posture Broker Client and Posture Broker Server.  This
+        provides security protection for a message dialog of the
+        groupings of attribute messages exchanged between the Posture
+        Broker Client and Posture Broker Server.  Such protection is
+        orthogonal to PA protections (which are end to end) and allows
+        for simpler Posture Collector and Validators to be implemented,
+        and for consolidation of cryptographic operations possibly
+        improving scalability and manageability.
+
+   PB-6 The PB protocol MUST support grouping of attribute messages
+        optimize transport of messages and minimize round trips.
+
+
+
+
+
+
+
+
+
+Sangster, et al.             Informational                     [Page 37]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+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-1 The PT protocol MUST NOT interpret the contents of PB messages
+        being transported, i.e., the data it is carrying must be opaque
+        to it.
+
+   PT-2 The PT protocol MUST be capable of supporting mutual
+        authentication, integrity, confidentiality, and replay
+        protection of the PB messages between the Posture Transport
+        Client and the Posture Transport Server.
+
+   PT-3 The PT protocol MUST provide reliable delivery for the PB
+        protocol.  This includes the ability to perform fragmentation
+        and reassembly, detect duplicates, and reorder to provide
+        in-sequence delivery, as required.
+
+   PT-4 The PT protocol SHOULD be able to run over existing network
+        access protocols such as 802.1X and IKEv2.
+
+   PT-5 The PT protocol SHOULD be able to run between a NEA Client and
+        NEA Server over TCP or UDP (similar to Lightweight Directory
+        Access Protocol (LDAP)).
+
+8.  Security Considerations
+
+   This document defines the functional requirements for the PA, PB, and
+   PT protocols used for Network Endpoint Assessment.  As such, it does
+   not define a specific protocol stack or set of technologies, so this
+   section will highlight security issues that may apply to NEA in
+   general or to particular aspects of the NEA reference model.
+
+   Note that while a number of topics are outside the scope of the NEA
+   WG and thus this specification (see section 3.1), it is important
+   that those mechanisms are protected from attack.  For example, the
+   methods of triggering an assessment or reassessment are out of scope
+   but should be appropriately protected from attack (e.g., an attacker
+   hiding the event indicating a NEA Server policy change has occurred).
+
+
+
+
+Sangster, et al.             Informational                     [Page 38]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+   NEA intends to facilitate detection and corrective actions for
+   cooperating endpoints to become compliant with network compliance
+   policies.  For example, it is envisioned that these policies will
+   allow deployers to detect out-of-date, inactive, or absent security
+   mechanisms on the endpoint that might leave it more vulnerable to
+   known attacks.  If an endpoint is more vulnerable to compromise, then
+   it is riskier to have this endpoint present on the network with other
+   valuable assets.  By proactively assessing cooperating endpoints
+   before their entrance to the network, deployers can improve their
+   resilience to attack prior to network access.  Similarly,
+   reassessments of cooperating endpoints on the network may be helpful
+   in assuring that security mechanisms remain in use and are up to date
+   with the latest policies.
+
+   NEA fully recognizes that not all endpoints will be cooperating by
+   providing their valid posture (or any posture at all).  This might
+   occur if malware is influencing the NEA Client or policies, and thus
+   a trustworthy assessment isn't possible.  Such a situation could
+   result in the admission of an endpoint that introduces threats to the
+   network and other endpoints despite passing the NEA compliance
+   assessment.
+
+8.1.  Trust
+
+   Network Endpoint Assessment involves assessing the posture of
+   endpoints entering or already on the network against compliance
+   policies to assure they are adequately protected.  Therefore, there
+   must be an implied distrusting of endpoints until there is reason to
+   believe (based on posture information) that they are protected from
+   threats addressed by compliance policy and can be trusted to not
+   propagate those threats to other endpoints.  On the network provider
+   side, the NEA Client normally is expected to trust the network
+   infrastructure systems to not misuse any disclosed posture
+   information (see section 9) and any remediation instructions provided
+   to the endpoint.  The NEA Client normally also needs to trust that
+   the NEA Server will only request information required to determine
+   whether the endpoint is safe to access the network assets.
+
+   Between the NEA Client and Server there exists a network that is not
+   assumed to be trustworthy.  Therefore, little about the network is
+   implicitly trusted beyond its willingness and ability to transport
+   the exchanged messages in a timely manner.  The amount of trust given
+   to each component of the NEA reference model is deployment specific.
+   The NEA WG intends to provide security mechanisms to reduce the
+   amount of trust that must be assumed by a deployer.  The following
+   sections will discuss each area in more detail.
+
+
+
+
+
+Sangster, et al.             Informational                     [Page 39]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+8.1.1.  Endpoint
+
+   For NEA to properly operate, the endpoint needs to be trusted to
+   accurately represent the requested security posture of the endpoint
+   to the NEA Server.  By NEA WG charter, the NEA reference model does
+   not explicitly specify how to detect or prevent lying endpoints that
+   intentionally misrepresent their posture.  Similarly, the detection
+   of malware (e.g., root kits) that are able to trick the Posture
+   Collectors into returning incorrect information is the subject for
+   research and standardization outside the IETF (e.g., Trusted
+   Computing Group [TCG]) and is not specifically addressed by the
+   model.  However, if such mechanisms are used in a deployment, the NEA
+   reference model should be able to accommodate these technologies by
+   allowing them to communicate over PA to Posture Validators or work
+   orthogonally to protect the NEA Client from attack and assure the
+   ability of Posture Collectors to view the actual posture.
+
+   Besides having to trust the integrity of the NEA Client and its
+   ability to accurately collect and report Posture Attributes about the
+   endpoint, we try to limit other assumed trust.  Most of the usage
+   models for NEA expect the posture information to be sent to the NEA
+   Server for evaluation and decision making.  When PA and/or PT level
+   security protections are used, the endpoint needs to trust the
+   integrity and potentially confidentiality of the trust anchor
+   information (e.g., public key certificates) used by the Posture
+   Collector and/or Posture Transport Client.  However, NEA
+   implementations may choose to send or pre-provision some policies to
+   the endpoint for evaluation that would assume more trust in the
+   endpoint.  In this case, the NEA Server must trust the endpoint's
+   policy storage, evaluation, and reporting mechanisms to not falsify
+   the results of the posture evaluation.
+
+   Generally the endpoint should not trust network communications (e.g.,
+   inbound connection requests) unless this trust has been specifically
+   authorized by the user or owner defined policy or action.  The NEA
+   reference model assumes the entire NEA Client is local to the
+   endpoint.  Unsolicited communications originating from the network
+   should be inspected by normal host-based security protective
+   mechanisms (e.g., firewalls, security protocols, Intrusion
+   Detection/Prevention System (IDS/IPS), etc.).  Communications
+   associated with a NEA assessment or reassessment requires some level
+   of trust particularly when initiated by the NEA Server
+   (reassessment).  The degree of trust can be limited by use of strong
+   security protections on the messages as dictated by the network
+   deployer and the endpoint user/owner policy.
+
+
+
+
+
+
+Sangster, et al.             Informational                     [Page 40]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+8.1.2.  Network Communications
+
+   Between the NEA Client and Server, there may exist a variety of types
+   of devices to facilitate the communication path.  Some of the devices
+   may serve as intermediaries (e.g., simple L2 switches) so they may
+   have the opportunity to observe and change the message dialogs.
+
+   The intermediary devices may fall into a few major categories that
+   impact our degree of trust in their operation.  First, some
+   intermediary devices may act as message forwarders or carriers for PT
+   (e.g., L2 switches, L3 routers).  For these devices we trust them not
+   to drop the messages or actively attempt to disrupt (e.g., denial of
+   service (DoS)) the NEA deployment.
+
+   Second, some intermediary devices may be part of the access control
+   layer of the network and as such, we trust them to enforce policies
+   including remediation, isolation, and access controls given to them
+   as a result on a NEA assessment.  These devices may also fill other
+   types of roles described in this section.
+
+   Third, some devices may act as a termination point or proxy for the
+   PT carrier protocol.  Frequently, it is expected that the carrier
+   protocol for PT will terminate on the NEA Client and Server so will
+   be co-resident with the PT endpoints.  If this expectation is not
+   present in a deployment, we must trust the termination device to
+   accurately proxy the PT messages without alteration into the next
+   carrier protocol (e.g., if inner EAP method messages are transitioned
+   from an EAP [EAP] tunnel to a RADIUS session).
+
+   Fourth, many networks include infrastructure such as IDS/IPS devices
+   that monitor and take corrective action when suspicious behavior is
+   observed on the network.  These devices may have a relationship with
+   the NEA Server that is not within scope for this specification.
+   Devices trusted by the NEA Server to provide security information
+   that might affect the NEA Server's decisions are trusted to operate
+   properly and not cause the NEA Server to make incorrect decisions.
+
+   Finally, other types of intermediary devices may exist on the network
+   between the NEA Client and Server that are present to service other
+   network functions beside NEA.  These devices might be capable of
+   passively eavesdropping on the network, archiving information for
+   future purposes (e.g., replay or privacy invasion), or more actively
+   attacking the NEA protocols.  Because these devices do not play a
+   role in facilitating NEA, it is essential that NEA deployers not be
+   forced to trust them for NEA to reliably operate.  Therefore, it is
+   required that NEA protocols offer security protections to assure
+   these devices can't steal, alter, spoof or otherwise damage the
+   reliability of the message dialogs.
+
+
+
+Sangster, et al.             Informational                     [Page 41]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+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 must be protected from compromise.
+   It is essential that NEA Server deployments properly safeguard these
+   systems from a variety of attacks from the network and endpoints to
+   assure their proper operation.
+
+   While there is a need to trust the NEA Server operation to some
+   degree, rigorous security architecture, analysis, monitoring, and
+   review should assure its network footprint and internal workings are
+   protected from attack.  The network footprint would include
+   communications over the network that might be subject to attack such
+   as policy provisioning from the policy authoring systems and general
+   security and system management protocols.  Some examples of internal
+   workings include protections from malware attacking the intra-NEA
+   Server communications, NEA Server internal logic, or policy stores
+   (particularly those that would change the resulting decisions or
+   enforcements).  The NEA Server needs to trust the underlying NEA and
+   lower layer network protocols to properly behave and safeguard the
+   exchanged messages with the endpoint.  The NEA reference model does
+   not attempt to address integrity protection of the operating system
+   or other software supporting the NEA Server.
+
+   One interesting example is where some components of the NEA Server
+   physically reside in different systems.  This might occur when a
+   Posture Validator (or a remote backend server used by a local Posture
+   Validator) exists on another system from the Posture Broker Server.
+   Similarly, the Posture Broker Server might exist on a separate system
+   from the Posture Transport Server.  When there is a physical
+   separation, the communications between the remote components of the
+   NEA Server must ensure that the PB session and PA message dialogs are
+   resistant to active and passive attacks, in particular, guarded
+   against eavesdropping, forgery and replay.  Similarly, the Posture
+   Validators may also wish to minimize their trust in the Posture
+   Broker Server beyond its ability to properly send and deliver PA
+   messages.  The Posture Validators could employ end-to-end PA security
+   to verify the authenticity and protect the integrity and/or
+   confidentiality of the PA messages exchanged.
+
+   When PA security is used, each Posture Validator must be able to
+   trust the integrity and potentially confidentiality of its trust
+   anchor policies.
+
+
+
+
+
+
+
+Sangster, et al.             Informational                     [Page 42]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+8.2.  Protection Mechanisms at Multiple Layers
+
+   Inherent in the requirements is a desire for NEA candidate protocols
+   throughout the reference model to be capable of providing strong
+   security mechanisms as dictated by the particular deployment.  In
+   some cases, these mechanisms may appear to provide overlapping or
+   redundant protections.  These apparent overlaps may be used in
+   combination to offer a defense in depth approach to security.
+   However, because of the layering of the protocols, each set of
+   protections offers slightly different benefits and levels of
+   granularity.
+
+   For example, a deployer may wish to encrypt traffic at the PT layer
+   to protect against some forms of traffic analysis or interception by
+   an eavesdropper.  Additionally, the deployer may also selectively
+   encrypt messages containing the posture of an endpoint to achieve
+   end-to-end confidentiality to its corresponding Posture Validator.
+   In particular, this might be desired when the Posture Validator is
+   not co-located with the NEA Server so the information will traverse
+   additional network segments after the PT protections have been
+   enforced or so that the Posture Validator can authenticate the
+   corresponding Posture Collector (or vice versa).
+
+   Different use cases and environments for the NEA technologies will
+   likely influence the selection of the strength and security
+   mechanisms employed during an assessment.  The goal of the NEA
+   requirements is to encourage the selection of technologies and
+   protocols that are capable of providing the necessary protections for
+   a wide variety of types of assessment.
+
+8.3.  Relevant Classes of Attack
+
+   A variety of attacks are possible against the NEA protocols and
+   assessment technologies.  This section does not include a full
+   security analysis, but wishes to highlight a few attacks that
+   influenced the requirement definition and should be considered by
+   deployers selecting use of protective mechanisms within the NEA
+   reference model.
+
+   As discussed, there are a variety of protective mechanisms included
+   in the requirements for candidate NEA protocols.  Different use cases
+   and environments may cause deployers to decide not to use some of
+   these mechanisms; however, this should be done with an understanding
+   that the deployment may become vulnerable to some classes of attack.
+   As always, a balance of risk vs. performance, usability,
+   manageability, and other factors should be taken into account.
+
+
+
+
+
+Sangster, et al.             Informational                     [Page 43]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+   The following types of attacks are applicable to network protocols
+   defined in the reference model and thus should be considered by
+   deployers.
+
+8.3.1.  Man-in-the-Middle (MITM)
+
+   MITM attacks against a network protocol exist when a third party can
+   insert itself between two communicating entities without detection
+   and gain benefit from involvement in their message dialog.  For
+   example, a malware infested system might wish to join the network
+   replaying posture observed from a clean endpoint entering the
+   network.  This might occur by the system inserting itself into and
+   actively proxying an assessment message dialog.  The impact of the
+   damage caused by the MITM can be limited or prevented by selection of
+   appropriate protocol protective mechanisms.
+
+   For example, the requirement for PT to be capable of supporting
+   mutual authentication prior to any endpoint assessment message
+   dialogs prevents the attacker from inserting itself as an active
+   participant (proxy) within the communications without detection
+   (assuming the attacker lacks credentials convincing either party it
+   is legitimate).  Reusable credentials should not be exposed on the
+   network to assure the MITM doesn't have a way to impersonate either
+   party.  The PT requirement for confidentiality-protected (encrypted)
+   communications linked to the above authentication prevents a passive
+   MITM from eavesdropping by observing the message dialog and keeping a
+   record of the conformant posture values for future use.  The PT
+   requirement for replay prevention stops a passive MITM from later
+   establishing a new session (or hijacking an existing session) and
+   replaying previously observed message dialogs.
+
+   If a non-compliant, active MITM is able to trick a clean endpoint to
+   give up its posture information, and the MITM has legitimate
+   credentials, it might be able to appear to a NEA Server as having
+   compliant posture when it does not.  For example, a non-compliant
+   MITM could connect and authenticate to a NEA Server and as the NEA
+   Server requests posture information, the MITM could request the same
+   posture from the clean endpoint.  If the clean endpoint trusts the
+   MITM to perform a reassessment and is willing to share the requested
+   posture, the MITM could obtain the needed posture from the clean
+   endpoint and send it to the NEA Server.  In order to address this
+   form of MITM attack, the NEA protocols would need to offer a strong
+   (cryptographic) binding between the posture information and the
+   authenticated session to the NEA Server so the NEA Server knows the
+   posture originated from the endpoint that authenticated.  Such a
+   strong binding between the posture's origin and the authenticating
+   endpoint may be feasible so should be preferred by the NEA WG.
+
+
+
+
+Sangster, et al.             Informational                     [Page 44]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+8.3.2.  Message Modification
+
+   Without message integrity protection, an attacker capable of
+   intercepting a message might be capable of modifying its contents and
+   causing an incorrect decision to be made.  For example, the attacker
+   might change the Posture Attributes to always reflect incorrect
+   values and thus prevent a compliant system from joining the network.
+   Unless the NEA Server could detect this change, the attacker could
+   prevent admission to large numbers of clean systems.  Conversely, the
+   attacker could allow a malware infested machine to be admitted by
+   changing the sent Posture Attributes to reflect compliant values,
+   thus hiding the malware from the Posture Validator.  The attacker
+   could also infect compliant endpoints by sending malicious
+   remediation instructions that, when performed, would introduce
+   malware on the endpoint or deactivate security mechanisms.
+
+   In order to protect against such attacks, the PT includes a
+   requirement for strong integrity protection (e.g., including a
+   protected hash like a Hashed Message Authentication Code (HMAC)
+   [HMAC] of the message) so any change to a message would be detected.
+   PA includes a similar requirement to enable end-to-end integrity
+   protection of the attributes, extending the protection all the way to
+   the Posture Validator even if it is located on another system behind
+   the NEA Server.
+
+   It is important that integrity protection schemes leverage fresh
+   secret information (not known by the attacker) that is bound to the
+   authenticated session such as an HMAC using a derived fresh secret
+   associated with the session.  Inclusion of freshness information
+   allows the parties to protect against some forms of message replay
+   attacks using secret information from prior sessions.
+
+8.3.3.  Message Replay or Attribute Theft
+
+   An attacker might listen to the network, recording message dialogs or
+   attributes from a compliant endpoint for later reuse to the same NEA
+   Server or just to build an inventory of software running on other
+   systems watching for known vulnerabilities.  The NEA Server needs to
+   be capable of detecting the replay of posture and/or the model must
+   assure that the eavesdropper cannot obtain the information in the
+   first place.  For this reason, the PT protocol is required to provide
+   confidentiality and replay prevention.
+
+   The cryptographic protection from disclosure of the PT, PB, or PA
+   messages prevents the passive listener from observing the exchanged
+   messages and thus prevents theft of the information for future use.
+   However, an active attacker might be able to replay the encrypted
+   message if there is no strong link to the originating party or
+
+
+
+Sangster, et al.             Informational                     [Page 45]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+   session.  By linking the encrypted message dialog to the
+   authentication event and leveraging per-transaction freshness and
+   keying exchanges, this prevents a replay of the encrypted
+   transaction.
+
+8.3.4.  Other Types of Attack
+
+   This section doesn't claim to present an exhaustive list of attacks
+   against the NEA reference model.  Several types of attack will become
+   easier to understand and analyze once the NEA WG has created
+   specifications describing the specific selected technologies and
+   protocols to be used within NEA.  One such area is Denial of Service
+   (DoS).  At this point in time, it is not practical to try to define
+   all of the potential exposures present within the NEA protocols, so
+   such an analysis should be included in the Security Considerations
+   sections of the selected NEA protocols.
+
+   However, it is important that the NEA Server be resilient to DoS
+   attacks as an outage might affect large numbers of endpoints wishing
+   to join or remain on the network.  The NEA reference model expects
+   that the PT protocol would have some amount of DoS resilience and
+   that the PA and PB protocols would need to build upon that base with
+   their own protections.  To help narrow the window of attack by
+   unauthenticated parties, it is envisioned that NEA Servers would
+   employ PT protocols that enable an early mutual authentication of the
+   requesting endpoint as one technique for filtering out attacks.
+
+   Attacks occurring after the authentication would at least come from
+   sources possessing valid credentials and could potentially be held
+   accountable.  Similarly, NEA protocols should offer strong replay
+   protection to prevent DoS-based attacks based on replayed sessions
+   and messages.  Posture assessment should be strongly linked with the
+   Posture Transport authentications that occurred to assure the posture
+   came from the authenticated party.  Cryptographic mechanisms and
+   other potentially resource intensive operations should be used
+   sparingly until the validity of the request can be established.  This
+   and other resource/protocol based attacks can be evaluated once the
+   NEA technologies and their cryptographic use have been selected.
+
+9.  Privacy Considerations
+
+   While there are a number of beneficial uses of the NEA technology for
+   organizations that own and operate networks offering services to
+   similarly owned endpoints, these same technologies might enhance the
+   potential for abuse and invasion of personal privacy if misused.
+   This section will discuss a few of the potential privacy concerns
+   raised by the deployment of this technology and offer some guidance
+   to implementers.
+
+
+
+Sangster, et al.             Informational                     [Page 46]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+   The NEA technology enables greater visibility into the configuration
+   of an endpoint from the network.  Such transparency enables the
+   network to take into consideration the strength of the endpoint's
+   security mechanisms when making access control decisions to network
+   resources.  However, this transparency could also be used to enforce
+   restrictive policies to the detriment of the user by limiting their
+   choice of software or prying into past or present uses of the
+   endpoint.
+
+   The scope of the NEA WG was limited to specifying protocols targeting
+   the use cases where the endpoints and network are owned by the same
+   party or the endpoint owner has established a clear expectation of
+   disclosure/compliance with the network owner.  This is a familiar
+   model for governments, institutions, and a wide variety of
+   enterprises that provide endpoints to their employees to perform
+   their jobs.  In many of these situations, the endpoint is purchased
+   and owned by the enterprise and they often reserve the right to audit
+   and possibly dictate the allowable uses of the device.  The NEA
+   technologies allow them to automate the inspection of the contents of
+   an endpoint and this information may be linked to the access control
+   mechanisms on the network to limit endpoint use should the endpoint
+   not meet minimal compliance levels.
+
+   In these environments, the level of personal privacy the employee
+   enjoys may be significantly reduced subject to local laws and
+   customs.  However, in situations where the endpoint is owned by the
+   user or where local laws protect the rights of the user even when
+   using endpoints owned by another party, it is critical that the NEA
+   implementation enable the user to control what endpoint information
+   is shared with the network.  Such controls imposed by the user might
+   prevent or limit their ability to access certain networks or
+   protected resources, but this must be a user choice.
+
+9.1.  Implementer Considerations
+
+   The NEA WG is not defining NEA Client policy content standards nor
+   defining requirements on aspects of an implementation outside of the
+   network protocols; however, the following guidance is provided to
+   encourage privacy friendly implementations for broader use than just
+   the enterprise-oriented setting described above.
+
+   NEA Client implementations are encouraged to offer an opt-in policy
+   to users prior to sharing their endpoint's posture information.  The
+   opt-in mechanism should be on a per-user, per-NEA Server basis so
+   each user can control which networks can access any posture
+   information on their system.  For those networks that are allowed to
+   assess the endpoint, the user should be able to specify granular
+   restrictions on what particular types and specific attributes Posture
+
+
+
+Sangster, et al.             Informational                     [Page 47]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+   Collectors are allowed to disclose.  Posture Validator
+   implementations are discouraged from having the default behavior of
+   using wild carded requests for posture potentially leading to
+   overexposure of information (see section 9.2).  Instead Posture
+   Validators, by default, should only request the specific attributes
+   that are required to perform their assessment.
+
+   Requests for attributes that are not explicitly allowed (or
+   specifically disallowed) to be shared should result in a user
+   notification and/or log record so the user can assess whether the
+   service is doing something undesirable or whether the user is willing
+   to share this additional information in order to gain access.  Some
+   products might consider policy-driven support for prompting the user
+   for authorization with a specific description of the posture
+   information being requested prior to sending it to the NEA Server.
+
+   It is envisioned that the owner of the endpoint is able to specify
+   disclosure policies that may override or influence the user's
+   policies on the attributes visible to the network.  If the owner
+   disclosure policy allows for broader posture availability than the
+   user policy, the implementation should provide a feedback mechanism
+   to the user so they understand the situation and can choose whether
+   to use the endpoint in those circumstances.
+
+   In such a system, it is important that the user's policy authoring
+   interface is easy to understand and clearly articulates the current
+   disclosure policy of the system including any influences from the
+   owner policy.  Users should be able to understand what posture is
+   available to the network and the general impact of this information
+   being known.  In order to minimize the list of restrictions
+   enumerated, use of a conservative default disclosure policy such as
+   "that which is not explicitly authorized for disclosure is not
+   allowed" might make sense to avoid unintentional leakage of
+   information.
+
+   NEA Server implementations should provide newly subscribing endpoints
+   with a disclosure statement that clearly states:
+
+      o What information is required
+
+      o How this information will be used and protected
+
+      o What local privacy policies are applicable
+
+   This information will empower subscribing users to decide whether the
+   disclosure of this information is acceptable considering local laws
+   and customs.
+
+
+
+
+Sangster, et al.             Informational                     [Page 48]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+9.2.  Minimizing Attribute Disclosure
+
+   One important issue in the design of the NEA reference model and
+   protocols is enabling endpoints to disclose minimal information
+   required to establish compliance with network policies.  There are
+   several models that could be considered as to how the disclosed
+   attribute set is established.  Each model has privacy related
+   benefits and issues that should be considered by product developers.
+   This section summarizes three potential models for how attribute
+   disclosure might be provided within NEA products and some privacy
+   implications potentially associated with each model.
+
+   The first model is easy to implement and deploy but has privacy and
+   potentially latency and scalability implications.  This approach
+   effectively defaults the local policy to send all known NEA Posture
+   Attributes when an assessment occurs.  While this might simplify
+   deployment, it exposes a lot of information that is potentially not
+   relevant to the security assessment of the system and may introduce
+   privacy issues.  For example, is it really important that the
+   enterprise know whether Firefox is being used on a system instead of
+   other browsers during the security posture assessment?
+
+   The second model involves an out-of-band provisioning of the
+   disclosure policy to all endpoints.  This model may involve the
+   enterprise establishing policy that a particular list of attributes
+   must be provided when a NEA exchange occurs.  Endpoint privacy policy
+   may filter this attribute list, but such changes could cause the
+   endpoint not to be given network or resource access.  This model
+   simplifies the network exchange as the endpoint always sends the
+   filtered list of attributes when challenged by a particular network.
+   However, this approach requires an out-of-band management protocol to
+   establish and manage the NEA disclosure policies of all systems.
+
+   The third model avoids the need for pre-provisioning of a disclosure
+   policy by allowing the NEA Server to specifically request what
+   attributes are required.  This is somewhat analogous to the policy
+   being provisioned during the NEA exchanges so is much easier to
+   manage.  This model allows for the NEA Server to iteratively ask for
+   attributes based on the values of prior attributes.  Note, even in
+   this model the NEA protocols are not expected to be a general purpose
+   query language, but rather allow the NEA Server to request specific
+   attributes as only the defined attributes are possible to request.
+   For example, an enterprise might ask about the OS version in the
+   initial message dialog and after learning the system is running Linux
+   ask for a different set of attributes specific to Linux than it would
+   if the endpoint was a Windows system.  It is envisioned that this
+
+
+
+
+
+Sangster, et al.             Informational                     [Page 49]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+   approach might minimize the set of attributes sent over the network
+   if the assessment is of a complex system (such as trying to
+   understand what patches are missing from an OS).
+
+   In each model, the user could create a set of per-network privacy
+   filter policies enforced by the NEA Client to prevent the disclosure
+   of attributes felt to be personal in nature or not relevant to a
+   particular network.  Such filters would protect the privacy of the
+   user but might result in the user not being allowed access to the
+   desired asset (or network) or being provided limited access.
+
+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.
+
+
+
+
+
+
+
+Sangster, et al.             Informational                     [Page 50]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+   [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 of this document would like to acknowledge the NEA
+   Working Group members who have contributed to previous requirements
+   and problem statement documents that influenced the direction of this
+   specification: Kevin Amorin, Parvez Anandam, Diana Arroyo, Uri
+   Blumenthal, Alan DeKok, Lauren Giroux, Steve Hanna, Thomas Hardjono,
+   Tim Polk, Ravi Sahita, Joe Salowey, Chris Salter, Mauricio Sanchez,
+   Yaron Sheffer, Jeff Six, Susan Thompson, Gary Tomlinson, John
+   Vollbrecht, Nancy Winget, Han Yin, and Hao Zhou.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sangster, et al.             Informational                     [Page 51]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+Authors' Addresses
+
+   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.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sangster, et al.             Informational                     [Page 52]
+
+RFC 5209                    NEA Requirements                   June 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Sangster, et al.             Informational                     [Page 53]
+