Network Endpoint Assessment (NEA): Overview and Requirements
RFC 5209

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]