One document matched: draft-ietf-nea-requirements-00.txt
NEA Working Group P. Sangster
Internet Draft Symantec
Expires: July 2007 H. Khosravi
Intel
M. Mani
Avaya
K. Narayan
Cisco Systems
J. Tardo
Nevis Networks
January 2007
Requirements for
Network Endpoint Assessment (NEA)
draft-ietf-nea-requirements-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she
is aware have been or will be disclosed, and any of which he
or she becomes aware will be disclosed, in accordance with
Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2007).
Sangster, et. al. Expires July 2007 [Page 1]
Internet Draft NEA Requirements Jan 2007
Abstract
This document defines the problem statement, scope and interface
(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 protective
mechanisms (e.g. anti-virus, firewall.)
In order to provide context for the requirements, a reference
model and terminology are introduced. This model is provided
for informational purposes but is based on the models used by
NAC [CNAC], NAP[NAP] and TNC[TNC].
Table of Contents
1. Introduction..................................................3
1.1 Conventions Used in This Document.........................4
2. Terminology...................................................4
3. Applicability.................................................6
3.1 Scope.....................................................6
3.2 Applicability of Environments.............................7
4. Problem Statement.............................................8
5. Reference Model...............................................9
5.1 Components...............................................10
5.1.1 NEA Client.........................................10
5.1.2 NEA Server.........................................13
5.2 Protocols................................................15
5.2.1 Posture Attribute Protocol (PA)....................15
5.2.2 Posture Broker Protocol (PB).......................15
5.2.3 Posture Transport Protocol (PT)....................16
5.3 Attributes...............................................16
5.3.1 Attributes Normally Sent by NEA Client.............16
5.3.2 Attributes Normally Sent by NEA Server.............17
6. Use Cases....................................................17
6.1 Initial Assessment.......................................18
6.1.1 Triggered by Network Connection Request............18
6.1.2 Triggered by Request for Network Service...........20
6.1.3 Triggered by Endpoint..............................22
6.2 Posture Re-Assessment....................................24
6.2.1 Triggered by NEA Client............................25
6.2.2 Triggered by NEA Server............................27
7. Requirements.................................................30
7.1 Common Protocol Requirements.............................30
Sangster, et. al. Expires July 2007 [Page 2]
Internet Draft NEA Requirements Jan 2007
7.2 Posture Attribute (PA) Protocol Requirements.............31
7.3 Posture Broker (PB) Protocol Requirements................32
7.4 Posture Transport (PT) Protocol Requirements.............33
8. Security Considerations......................................34
8.1 Trust....................................................34
8.1.1 Client Components..................................35
8.1.2 Network Communications.............................36
8.1.3 Server Components..................................37
8.2 Overlapping Protections..................................37
8.3 Relevant Classes of Attack...............................38
8.3.1 Man-in-the-Middle (MITM)...........................38
8.3.2 Message Modification...............................39
8.3.3 Message Replay or Attribute Theft..................39
8.3.4 Other Types of Attack..............................40
9. Privacy Considerations.......................................41
9.1 Implementer Considerations...............................42
9.2 Minimizing Attribute Disclosure..........................43
10. References..................................................44
10.1 Normative References....................................44
10.2 Informative References..................................45
Acknowledgments.................................................45
Authors’ Addresses..............................................45
1. Introduction
Today, most network providers can leverage existing standards-
based technologies to restrict access to the network based
upon criteria such as the requesting system's user or host-
based identity, source IP address or physical access point.
However these approaches still leave the network vulnerable to
malware-based attack, when an authorized but infected system
is admitted and the malware is able to spread throughout the
internal network.
As a result, network operators need the ability to
preemptively detect systems that are vulnerable or already
infected with malware and hence potentially dangerous to the
network. If a system is determined to be vulnerable to attack
by lacking proper defensive mechanisms such as the absence of
up to date critical security patches or anti-virus software,
there should be a way to safely repair (remediate) the system
so that it can be subsequently trusted to join and operate on
the network.
Network Endpoint Assessment (NEA) architectures have been
implemented in the industry allowing the network to have
visibility into the configuration of the system (e.g. security
Posture) when the system requests access to the network or at
any time the system is connected to the network so that it’s
risk profile can be factored into various admission and access
control decisions. NEA typically involves the use of special
client software running on the requesting machine that
observes and reports on the Posture of the system to network
infrastructure. The infrastructure has corresponding
Sangster, et. al. Expires July 2007 [Page 3]
Internet Draft NEA Requirements Jan 2007
Validator components that are capable of evaluating the
Posture information and feeding the result to appropriate
authorization entities that make decisions about network and
application access.
Finally the admission decision is provisioned to the
enforcement mechanisms on the network and/or system requesting
access. The decision might allow for no access, limited
access (possibly to allow for remediation), or full access to
the network. While the NEA Reference Model recognizes there is
a link between an Endpoint Assessment and the enforcement of
the Assessment 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 interoperability. Some examples of such architectures
include: Trusted Computing Group’s TNC [TNC], Microsoft’s NAP
[NAP], Cisco’s NAC [CNAC].) These technologies assess the
software or hardware configuration of endpoint devices for the
purposes of monitoring or enforcing compliance of endpoints to
an organization's policy on access to the network. These
architectures are not interoperable since most of the
technologies used to implement the architecture are not
standards.
The NEA working group is working on defining standard
protocols so as to enable interoperability between devices
from different vendors allowing network owners to deploy truly
heterogeneous solutions. This document describes the
requirements for NEA candidate technologies and protocols.
1.1 Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in [KEYWORDS].
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 from a set of
Endpoint Components such that the appropriate validators may
evaluate the Posture against compliance policy.
Sangster, et. al. Expires July 2007 [Page 4]
Internet Draft NEA Requirements Jan 2007
Assertion Attributes - Class of Attribute including re-usable
information about the success of a prior Assessment of the
Endpoint. This could be used to optimize subsequent
Assessments by avoiding a full Posture re-Assessment. For
example, this type of Attribute might be issued specifically
to a particular Endpoint, dated and signed by the NEA Server
allowing that Endpoint to re-use 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 status of a Component
property. NEA recognizes a variety of classes of Attributes
particular to their usage: Assertion Attributes, Compliance
Claim Attributes, Posture Attributes, Policy Attributes,
Request Attributes, Result Attributes, and Remediation
Attributes. Within each class, there are two different types
of Attributes: core and vendor-specific. The core attributes
will be standardized by the NEA WG.
Compliance Claim Attribute - Class of Attribute used by an NEA
Client to claim that the Endpoint complies with a particular
policy. For example, these Attributes are used when the NEA
Client is offered Policy Attributes and wishes to claim
compliance with the Policy rather then provide Posture
Attributes to show compliance.
Component - Software, hardware or firmware entity performing a
particular logical function on the Endpoint. For example, a
component may be a Posture Collector designed to ascertain the
Posture of another Component such as a particular vendor
product (e.g. Norton Anti-Virus) running on the Endpoint.
Dialog - Sequence of request/response Messages exchanged
Endpoint - Any host computing device that can be connected to
a network. This includes: laptops, desktops, servers, cell
phone or any device with an IP address.
Message - Self contained unit of communication between
Components. For example, a PA Message might carry a set of
Posture Attributes from a Posture Collector to a Posture
Validator.
Owner - the role of an entity who is the legal, rightful
possessor on 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 not assert any policies limiting use of asset.
Sangster, et. al. Expires July 2007 [Page 5]
Internet Draft NEA Requirements Jan 2007
Policy Attributes - Class of Attribute describing (or
referencing) the desired policy to be met by a set of
Components. For example, Policy Attributes might be used to
enable an NEA Client to determine whether the Endpoint is
compliant without disclosing Posture information by making
claims in Compliance Claim Attributes.
Posture - Configuration and/or status of hardware or software
Component(s) on an Endpoint as it pertains to an
organization’s security policy.
Posture Attributes - Class of Attribute describing a quality
or characteristic of a Component. For example, a Posture
Attribute might describe the version of a Component installed
on the system. Posture Attributes are normally created by a
Posture Collector for inclusion in a Posture description of an
Endpoint.
Request Attributes - Class of Attribute containing the list of
Attributes the NEA Client is requested to send to the NEA
Server.
Remediation Attributes - Class of Attribute including the
remediation instructions for how to bring an endpoint into
compliance with one or more policies.
Result Attributes - Class of Attribute 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 the Endpoint
was considered compliant or not. Multiple of these Attributes
may be used allowing for Posture Validator level decisions to
be communicated in addition to an overall, global posture
decision from the Posture Broker Server.
Session - Stateful connection (e.g. PB protocol described in
Section 3) capable of carrying one or more Messages from
multiple subscribed Posture Collectors and Validators.
3. Applicability
This section discusses the scope of technologies being
standardized and the network environments where its envisioned
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. When used with standard lower layer protocols, the
Sangster, et. al. Expires July 2007 [Page 6]
Internet Draft NEA Requirements Jan 2007
PA and PB protocols are intended to allow interoperability
between an NEA Client from one vendor and an NEA Server from
another. This specification will not focus on the interfaces
between NEA Reference Model Components nor requirements their
internals. Any discussion of these aspects is provided 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 providing
restricted network access,
o Developing standard protocols for remediation of non-
compliant Endpoints,
o Detecting or handling lying Endpoints.
3.2 Applicability of Environments
Because the NEA model is based on special software being
present on the Endpoint and in the network infrastructure and
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. Ultimately, the use of NEA within a
deployment is not restricted by 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 which provide
equipment to employees to perform their duties. These
employees are likely bound under an employment contract which
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. Environments where
the Endpoint is owned by a party (possibly even the User)
where the party 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, may wish a similar level of access
and be willing to conform to its policies. NEA technologies
may be applicable to this situation.
Sangster, et. al. Expires July 2007 [Page 7]
Internet Draft NEA Requirements Jan 2007
Conversely, some environments where NEA is not expected to be
applicable would be environments where the Endpoint is owned
by a User and 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
which 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. Such an assessment could
amount to an invasion of privacy of the contractor.
Other environments are more difficult to determine whether NEA
is a good fit, so the NEA WG intends to steer clear of such
areas. In particular environments where the Owners of the
Endpoint, the network infrastructure and/or the network
service provider are different and do not have a strong
binding contract(s) establishing their expectations for
conformance and willingness to disclose information to each
other security policies.
4. Problem Statement
NEA technology may be used for several purposes. 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 OS configuration and have certain security
applications enabled, e.g. anti-virus software, host intrusion
protection 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 guest 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 monitor compliance
of all NEA-capable Endpoints in a timely fashion and
facilitate Endpoint remediation where needed.
The decision of how to handle non-compliant Endpoints can be
made by the network administrator and factor in information
from other security mechanisms on the network (e.g.
authentication.) Remediation instructions or warnings may be
sent to the endpoint. Also, network access technologies can
use the NEA Assessment results to restrict or deny access to
an Endpoint allowing vulnerabilities to be addressed before an
Sangster, et. al. Expires July 2007 [Page 8]
Internet Draft NEA Requirements Jan 2007
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.
Re-assessment is an important part of NEA technology; it
allows Endpoints to be re-assessed in case there is a
violation of a security policy. For example, re-assessment
may be triggered by a NEA Client if a User disables a security
application such as a host firewall on the Endpoint. Re-
assessment also assists in keeping Endpoints connected to the
network up to date with fixes and patches published by
security application vendors. Another use of NEA technology
may be to supplement information in inventory databases. In
organizations that attempt to keep track of their assets,
inventory databases tend to be incomplete and out-of-date.
NEA technology may be used to verify or supplement information
stored about an organization's assets.
A NEA deployment is intended to benefit Endpoints that report
accurate Posture information in an effort to make them less
vulnerable to compromised Endpoints on the network. Handling
compromised Endpoints that report inaccurate Posture
information is out of scope.
NEA technology can be used to address the above problem
covering a range of ways of connecting to the network
including (but not limited to) wired and wireless LAN access,
remote access via IPSEC or SSL VPN, or gateway access. NEA
technology can also be used to monitor and report compliance
for Endpoints when they try to access certain mission critical
applications within an enterprise by employing 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
includes the major Components of the NEA Client and Server as
well as the protocols they use to communicate at various levels
(e.g. PA is carried by the PB protocol.)
Sangster, et. al. Expires July 2007 [Page 9]
Internet Draft NEA Requirements Jan 2007
+-------------+ +--------------+
| Posture | <--------PA--------> | Posture |
| Collectors | | Validators |
| (1 ...N) | | (1 ...N) |
+-------------+ +--------------+
| |
| |
| |
+-------------+ +--------------+
| Posture | | Posture |
| Broker | <--------PB--------> | Broker |
| Client | | Server |
+-------------+ +--------------+
| |
| |
+-------------+ +--------------+
| Posture | | Posture |
| Transport | <--------PT--------> | Transport |
| Client | | Server |
+-------------+ +--------------+
NEA CLIENT NEA SERVER
Figure 1: NEA Reference Model
5.1 Components
5.1.1 NEA Client
The NEA Client is resident on an Endpoint device and comprises
of the following components:
o Posture Collector
o Posture Broker Client
o Posture Transport Client
5.1.1.1 Posture Collector
The Posture Collector is the Component that is responsible for
responding to requests for Posture information from the
Posture Broker Client and receiving Posture Assessment
requests (Request Attributes,) Policy information (Policy
Attributes,) Assessment decisions (Result Attributes) and
remediation instructions (Remediation Attributes.) A single
NEA Client can have several Posture Collectors capable of
collecting core and/or vendor-defined Posture Attributes for
particular Endpoint Components. Typical examples include
Posture Collectors that provide information about Operating
System (OS) patch levels, anti-virus software, and security
applications on the Endpoint such as host firewall or an IDS.
Posture Collectors may also be capable of evaluating rules and
asserting Posture decisions.
Sangster, et. al. Expires July 2007 [Page 10]
Internet Draft NEA Requirements Jan 2007
Each Posture Collector will be associated with an identifier
that enables it to be the specified as the destination in a PA
Message. The Posture Broker Client uses this identifier to
route Messages to this collector. This identifier might be
dynamic (e.g. assigned by the Posture Broker Client upon
registration) or more static (e.g. provided during
registration) or a function of the Attribute Messages the
collector desires to receive (e.g. Message type subscription.)
The NEA model allocates the following responsibilities to the
Posture Collector Component:
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 the
Component(s) on the Endpoint and returning this
information in Posture Attributes.
- Recognizing a recently issued (cached) Assertion
Attribute that might serve to prove compliance and
returning this attribute instead of Posture
information.
o Receiving Policy Attributes indicating the policies that
need to be met to be considered compliant. The collector
would obtain the Posture information from Component(s) on
the Endpoint and compare the information with the
provided (or referenced) security policy. The result
would be sent back to the Validator in Compliance Claim
Attributes.
- If the Policy Attributes merely reference a
compliance policy, the collector may need to fetch
or locate this policy.
o Receiving Remediation Attributes containing instruction
on how to update the Component(s) on the Endpoint. This
could require the collector to interact with the User,
Owner and/or a remediation server.
o Monitoring the Posture of Component(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. Expires July 2007 [Page 11]
Internet Draft NEA Requirements Jan 2007
The above list describes the model’s view of the possible
responsibilities of the Posture Collector. Recall that this is
not a set of requirements for what each Posture Collector
implementation must support.
5.1.1.2 Posture Broker Client
The Posture Broker Client is a Component that is both a
multiplexer and a de-multiplexer. The Posture Broker Client is
responsible for de-multiplexing the Posture information
request from the NEA Server and forwarding the request to the
appropriate Posture Collectors. The Posture Broker Client also
multiplexes the responses from the Posture Collector and
returns them to the NEA Server. A particular NEA Client will
have one Posture Broker Client.
The NEA model allocates the following responsibilities to the
Posture Broker Client Component:
o Maintaining a registry of Posture Collectors and
allowing for Posture Collectors to register/un-register.
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 re-Assessment.
o Providing user notification about the global Posture
decision and other user Messages sent by the NEA Server.
5.1.1.3 Posture Transport Client
The Posture Transport Client is a component responsible for
establishing the 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 Clients on a
particular NEA Client.
The NEA model allocates the following responsibilities to the
Posture Transport Client Component:
o Initiating and maintaining the communication channel to
the NEA Server, the Posture transport client hides the
details of the underlying carrier which could be a Layer
2 or Layer 3 protocol.
o Providing cryptographic protection for the Message dialog
between the NEA Client and NEA Server.
Sangster, et. al. Expires July 2007 [Page 12]
Internet Draft NEA Requirements Jan 2007
5.1.2 NEA Server
The NEA Server will typically comprise of the following
logical components:
o Posture Validator
o Posture Broker Server
o Posture Transport Server
The Posture Validator can 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 a Component that is responsible for
assessing the Posture Attributes from the corresponding
Posture Collector and determining the result of the
Assessment. The Posture Validator performs the Posture
Assessment for one or more Components and creates the result
and if necessary the remediation instructions. The Posture
Validator can request a set of primitive attributes or can
pass compliance policies that might be evaluated by the
Posture Collector. The response from the Posture Collector
could be a set of Attributes or a set of assertions in case of
client based evaluation.
Each Posture Validator will be associated with an identifier
that enables it to be the 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. assigned by the Posture Broker Server upon
registration) or more static (e.g. provided during
registration) or a function of the Attribute Messages the
validator desires to receive (e.g. Message type subscription.)
Posture Validators can be co-located on the NEA Server or can
be hosted on separate servers. A particular NEA Server is
required to handle several Posture Validators.
The NEA model allocates the following responsibilities to the
Posture Validator Component:
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
from various Component(s) on the NEA Client.
- Policy Attributes that indicate to the Posture
Collector the policies that need to met by various
Component(s) for them to be considered compliant.
Sangster, et. al. Expires July 2007 [Page 13]
Internet Draft NEA Requirements Jan 2007
o Receiving Attributes from the Posture Collector. The
response from the Posture Collector may include:
- Posture Attributes collected from various
Component(s).
- Assertion Attributes that indicate the compliance
result from a prior Assessment.
- Compliance Claim Attributes in response to Policy
Attributes sent in the request.
o Assessing the Posture of the Component(s) based on the
various 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:
- Results Attribute that communicates the Posture
Assessment Result.
- Remediation Attributes that communicate the
Remediation Instructions to the Posture Collector.
o Monitoring out-of-band updates that trigger re-assessment
and require notifications to be sent to the Posture
Broker Server.
o Providing cryptographic protection for Attributes sent to
the Collector and offering cryptographic verification of
the Attributes received from the Collector.
5.1.2.2 Posture Broker Server
The Posture Broker Server is a Component that acts as a
multiplexer and a de-multiplexer for Attribute Messages. The
Posture Broker Client multiplexes the Attribute Messages, e.g.
Messages containing Request Attribute(s) from the Posture
Validators and returns them to the NEA Client. The Posture
Broker Server de-multiplexes the Attribute Messages received
from the NEA Client and forwards them to the appropriate
Posture Validators. The Posture Broker Server is also
responsible for computing the global Posture decision based on
individual Posture Assessment results from the various Posture
Validators, this global Posture decision is sent back to the
NEA Client. 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 Component:
o Maintaining a registry of Posture Validators and
allowing for Posture Validators to register/un-register.
Sangster, et. al. Expires July 2007 [Page 14]
Internet Draft NEA Requirements Jan 2007
o Multiplexing and de-multiplexing Posture Messages
between the NEA Client and the relevant Posture
Validators.
o Communicating with remote Posture Validators and
providing cryptographic protection for this
communication.
o Computing the global Posture decision based on Posture
Assessment results from the various Posture Validators.
5.1.2.3 Posture Transport Server
The Posture Transport Server is a component responsible for
establishing the 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 Servers on a
particular NEA Server. A particular Posture Transport Server
will typically handle requests from several NEA Clients.
The NEA model allocates the following responsibilities to the
Posture Transport Server Component:
o Initiating and maintaining a communication channel with
potentially several NEA Clients.
o Providing cryptographic protection for Posture
information transported on the communication channel.
5.2 Protocols
5.2.1 Posture Attribute Protocol (PA)
PA is a protocol that carries Attribute Messages between a
Posture Collector and its associated Posture Validator. The PA
protocol is required to handle several types of Attributes
including Posture Attributes, Request Attributes, Result
Attributes, Policy Attributes, Compliance Claim Attributes,
Assertion Attributes and Remediation Attributes. The PA
protocol also provides the requisite encoding and
cryptographic protection for the Posture Attributes.
5.2.2 Posture Broker Protocol (PB)
PB is a protocol that carries aggregate Attribute Messages
between the requested Posture Collectors on the NEA Client and
the corresponding Posture Validators on the NEA Server
involved in a particular Assessment. The PB protocol creates
and manages 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 Posture decision in the Result Attribute from the
Posture Broker Server to the Posture Broker Client.
Sangster, et. al. Expires July 2007 [Page 15]
Internet Draft NEA Requirements Jan 2007
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 must be capable of transporting
Messages for Assessment during network connection request and
after network connectivity has been established.
The PT protocol provides reliable Message delivery, mutual
authentication and cryptographic protection for the PB
Messages.
5.3 Attributes
The PA protocol is responsible for the exchange of Attributes
between a Posture Collector and Posture Validator. 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 (core)
set of Attributes that are expected to be supported by all
Posture Collectors, but outside this set Posture Collectors may
support additional vendor-specific attributes.
As discussed in the Use Cases section below, depending on the
deployment scenario, different types of Attributes may be used.
The Attribute classes defined in this specification may be merged
when the NEA WG defines the name space and schema for each
Attribute class, but for now this specification recognizes their
distinct roles. This section summarizes the purpose of each class
of Attribute and how they are generated.
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. For example a set of Posture
Attributes might describe the status of the 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 claiming recent prior
compliance to policy in hopes of avoiding a re-assessment.
These attributes might consist of NEA Server provided
attributes (state) describing a prior evaluation (e.g.
opaque to Endpoint, signed, time stamped items stating
specific results) or might consist of NEA Client identity
information used by the NEA Server to locate state about
prior decisions (e.g. system-bound cookie.)
Sangster, et. al. Expires July 2007 [Page 16]
Internet Draft NEA Requirements Jan 2007
o Compliance Claim Attributes - Attributes claiming compliance
with a particular policy provided by the NEA Server (in
Policy Attributes.)
5.3.2 Attributes Normally Sent by NEA Server:
o Request Attributes - Attributes which define the specific
Posture information desired by the NEA Server. These
attributes might effectively form a template that the Client
fills in (subject to local policy restrictions) with the
specific value corresponding to each Attribute.
o Policy Attributes - Attributes including the NEA Server’s
network access policies that the Endpoint must meet. These
Attributes are normally sent when the Client is empowered to
merely provide the NEA Server with a compliance claim (in
Result Attributes) without providing Posture Attributes.
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 thru just the global
decision.
o Remediation Attributes - Attributes that describe 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 decision was that the Endpoint is
not currently compliant. Remediation and Result Attributes
may both exist within an NEA Server Attribute Message.
6. Use Cases
This section discusses 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 require support from the NEA protocols.
We broadly classify the use cases into two categories each
with their 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 might be triggered by a
request to join a network, request to use a service or a
desire to understand the Posture of a system.
Sangster, et. al. Expires July 2007 [Page 17]
Internet Draft NEA Requirements Jan 2007
o Re-assessment - evaluation of the Posture of an endpoint
that has previously been assessed. This could occur for
a variety of reasons including the NEA Client or Server
recognizing an occurrence affecting the endpoint which
might raise its risk level. This could be as simple as
it having been a long time since its last re-assessment.
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 that 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 their Posture evaluated again do not
qualify for this category of use case.
Posture P.Broker Transport Transport P.Broker Posture
Collectors Client Client Server Server Validators
| | | | | |
| | client requests network access |
| | |---------->| | |
| | | |-------->|Posture reqs
| | | | |<----------|
| | | Posture Req | |
| | Pos Req |<----------|<--------| |
| Pos Req |<--------| | | |
|<--------| | | | |
|Pos Resp | | | | |
|-------->|Pos Resp | | | |
| |-------->| Posture Resp | |
| | |---------->|-------->| Pos Resp |
| | | | |---------->|
| | | | | Decisions |
| | | Posture Decision |<----------|
| | Decision|<----------|<--------| |
| Decision|<--------| | | |
|<--------| | | | |
| | | | | |
Figure 2: Illustration of NEA Initial Assessment Use case
6.1.1 Triggered by Network Connection Request
This use case focuses on Assessments performed at the time an
Endpoint attempts to join a network. 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. This approach could be used to help detect infected
Endpoints before they are admitted to the network and might
spread the virus.
Sangster, et. al. Expires July 2007 [Page 18]
Internet Draft NEA Requirements Jan 2007
6.1.1.1 Example
An IT employee returning from vacation boots his office
desktop computer which 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 network determines that
the system is lacking a recent security patch designed to fix
a serious vulnerability and places the system on a restricted
access network. The desktop follows the network provided
remediation instructions to download and install the necessary
patch. Later, the desktop requests again to join the network
and this time is allowed on the enterprise network after a
full Assessment.
6.1.1.2 Possible flows and Protocol Usage
The following describes the Message flows through the NEA
Reference Model for the described example:
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 notified of
the request to join the wired network.
3. Based upon compliance policy the Posture Broker Server
contacts the OS Patch, Firewall and Anti-Virus Posture
Validators to request the necessary Posture. Each Posture
Validator creates a PA Message containing the desired
Request Attributes for the desktop system.
4. The Posture Broker Server aggregates the Request
Attributes from the Posture Validators and sends them to
the NEA Client on the desktop using the Posture Transport
Server.
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 Request Attributes to the Firewall, OS 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 Posture
Attributes that are authorized in a PA Message to the
Posture Broker Client.
8. The Posture Broker Client aggregates these 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 which de-multiplexes the Message
and sends the appropriate Posture Attributes to the
corresponding Posture Validator.
Sangster, et. al. Expires July 2007 [Page 19]
Internet Draft NEA Requirements Jan 2007
10. Each Posture Validator compares the contents of the
Posture Attribute Message it receives with the expected
values defined in its policy.
11. The Anti-Virus and Firewall Posture Validators return a
Posture Assessment Result stating its compliant to the
Posture Broker Server, but the OS Patch Posture Validator
returns non-compliant and a PA Message with Result and
Remediation Attributes.
12. The Posture Broker Server sends the Result and Remediation
Attributes in a PB Message to the Posture Broker Client
13. The Posture Broker Client delivers the Result and
Remediation Attributes to the OS Patch Posture Collector
which interacts with the User to download and install the
needed patches.
14. Upon completion, the above steps 1-10 are repeated.
15. This time the OS Patch Posture Validator (step 11) returns
a success status and the Posture Broker Server returns a
successful Result Attribute in a PB Message indicating a
global success.
16. The Posture Broker Client receives the successful Result
Attribute and the IT employee’s desktop is now on the
network.
6.1.1.3 Impact on Requirements
o Posture Assessment before Endpoint allowed on network
o Endpoint sends Posture Attributes
o NEA Server sends Remediation Attributes
o NEA Client causes a re-assessment to join network after
remediation
6.1.2 Triggered by Request for Network Service
In this use-case, the Endpoint was allowed access to the
network without a NEA Posture validation. Now the Endpoint is
requesting use of a protected resource or service which
results in the need for an Assessment. There are a variety of
possible resources or network services that could be involved
with this use case (e.g. critical application server seeking
tighter security assurances of the accessing client
endpoints.)
6.1.2.1 Example
The CEO of a small company working from home wishes to
establish a VPN into the office to read e-mail. The CEO is
already on the home IP-based network which did not perform an
Initial Assessment. When the VPN service request reaches the
company’s gateway, it wishes some assurance the CEO’s system
is virus protected before allowing access to the company
network. The gateway’s policies require the system be running
anti-virus that has up to date signatures, but does not wish
to expose details (potentially personal in nature) of what is
running on the system to the network. The gateway sends its
Sangster, et. al. Expires July 2007 [Page 20]
Internet Draft NEA Requirements Jan 2007
specific policy on allowable anti-virus products and versions
to the CEO’s system and inquires as to whether it is
compliant. The CEO’s system assesses the anti-virus software
and determines it meets the request policy, thus it sends a
Message claiming it is compliant. The gateway decides to
trust the claim and allow the system on the network.
6.1.2.2 Possible flows and Protocol Usage
The following describes the Message flows through the NEA
Reference Model for the remote user using a VPN to access the
enterprise network example:
1. CEO’s computer initiates a remote access request to the
VPN gateway via his home network.
2. The VPN gateway triggers an authentication exchange with
the Endpoint. The protocol that carries this exchange does
double duty by also carrying the Posture Transport
protocol.
3. The VPN gateway notifies the Posture Transport Server that
a new VPN session has been requested which triggers the
Posture Broker Server to initiate an NEA assessment.
4. The Posture Broker Server policy requires that Anti-Virus
be checked so it contacts the Anti-Virus Posture
Validator.
5. Since in this case the Anti-Virus Posture Validator policy
trusts the NEA Client to perform the assessment it creates
a PA Message containing Policy Attributes including the
most recent Posture values describing the required Anti-
Virus policy that the CEO’s computer must meet.
6. The Posture Broker Server assembles the PB protocol
message containing the Policy Attributes, and forwards
them to the Posture Broker Client on the Endpoint over the
PT protocol.
7. The gateway forwards the PB Message to the Posture
Transport Client in the NEA Client, which passes the
Message to its Posture Broker Client.
8. The Posture Broker Client extracts the PA Message from the
PB Message and delivers it to the Anti-Virus Posture
Collector for processing.
9. The Anti-Virus Posture Collector finds Policy Attributes
(instead of the normal Request Attributes) so is empowered
to make a claim of compliance with respect to the included
(or referenced) policy.
10. The Anti-Virus Posture Collector obtains information about
the running Anti-Virus software and compares this
information with the provided Policy Attributes.
11. In this case, it determines the CEO’s system is compliant
with the policy and creates a PA Message containing
Compliance Claim Attribute(s) describing the compliance.
The PA Message is returned to the Posture Broker Client.
12. The Posture Broker Client takes the Compliance Claims
Attributes from the Posture Collector, assembles a PB
protocol message, and forwards it to NEA Server, via the
gateway, over the PT protocol.
Sangster, et. al. Expires July 2007 [Page 21]
Internet Draft NEA Requirements Jan 2007
13. The gateway in turn forwards the PT protocol messages to
the Posture Transport Server on the NEA Server.
14. The Posture Broker Server de-multiplexes the Compliance
Claims Attributes and delivers them to the Anti-Virus
Posture Validator. The Posture Validator can return Result
Attributes indicating compliance status and, if required,
Remediation Attributes to the Posture Broker Server. In
this example, the Anti-Virus Posture Validator trusts the
claims that the CEO’s system is compliant so creates a PA
Message containing a Result Attribute stating the system
is compliant and returns a successful Posture Assessment
Decision.
15. The Posture Broker Server creates a PB Message containing
the PA Message and includes a successful global compliance
decision, and returns it and specific Result messages to
the NEA Client via the PB protocol.
16. The Posture Transport protocol also informs the gateway of
the compliance status, so that it can take the appropriate
enforcement action if required. The VPN authentication
process continues, in this case over the same physical
protocol as used for PT.
17. Upon successful VPN authentication appropriate enforcement
policies are applied. The gateway allows normal access to
an Endpoint that is in compliance.
6.1.2.3 Impact on Requirements
o Posture Assessment after Endpoint on network, triggered by
service request
o NEA Server requests only anti-virus Posture
o Endpoint sends Compliance Claim Attributes rather than
Posture Attributes
o NEA Server decision based only on Compliance Attributes (no
Posture Attributes sent)
6.1.3 Triggered by Endpoint
This use case highlights that an Endpoint (possibly caused by
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.3.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 requests a Posture Assessment. The network performs
an Initial Assessment of the system and determines it’s
compliant but the anti-virus protection is not in use. The
Sangster, et. al. Expires July 2007 [Page 22]
Internet Draft NEA Requirements Jan 2007
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.3.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 which causes an assessment to be
triggered.
3. The Posture Transport Client establishes the transport
channel to the Posture Transport Server causing a new
protocol context exchange to be initiated.
4. The Posture Broker Server detects the new Session and
consults policy to determine which Posture Validators to
involve in the assessment. The Posture Broker Server
contacts several Posture Validators including the Anti-
Virus Posture Validator.
5. The Posture Validators involved create PA Messages
containing Request Attributes for information desired
about the terminal room computer based on the school’s
security policy.
6. The Posture Broker Server assembles a PB Message including
each of the PA Messages from the Posture Validators.
7. The Posture Transport Server sends the PB Message to the
Posture Transport Client where it is passed on to the
Posture Broker Client.
8. The Posture Broker Client on the student’s computer de-
multiplexes the PA Message and delivers them to the
corresponding Posture Collectors.
9. 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 Posture
Attributes to the Posture Broker Client.
10. 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.
11. The Posture Broker Server separates and distributes the
Posture Collector PA Messages to the associated Posture
Validators.
12. The Posture Validators determine whether the Posture
Attributes included in the PA Message are compliant with
their specific policies and returns a Posture Assessment
Decision to the Posture Broker Server. The anti-virus
Sangster, et. al. Expires July 2007 [Page 23]
Internet Draft NEA Requirements Jan 2007
Posture Validator returns a non-compliant decision because
the Anti-Virus software is not running. In case the User
wishes to activate the Anti-Virus software, the Validator
creates Remediation Attributes.
13. The Posture Broker Server determines the global compliance
decision based on each Validator’s assessment decision and
sends Result Attributes containing the global decision and
the Anti-Virus’s Remediation Attributes. In this case the
Result Attribute contains a compliant decision (despite
the single remediation attributes) 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 were the case according to the
other Posture Validators.) This information is included
in a PB Message.
14. The Posture Transport Server sends the PB Message to the
Posture Transport Client which provides the Message to the
Posture Broker Client.
15. The Posture Broker Client on the student’s computer
examines the Result Attribute’s global decision and
reports to the Student that the system was deemed to be
compliant, but that an advisory was included.
16. The Posture Broker Client provides the Remediation
Attributes to the Anti-Virus Posture Collector which
interacts with the User to explain how to turn on Anti-
Virus to improve the local protections.
17. The student turns on the Anti-Virus software and on
completion steps 1-10 are repeated.
18. This time the Anti-Virus Posture Validator returns a
success status and the Posture Broker Server returns a
successful Result Attribute in a PB Message indicating a
global success.
19. The Posture Broker Client receives the successful Result
Attribute on the student’s computer and the student now
uses the computer for his/her assignment.
6.1.3.3 Impact on Requirements
o Voluntary, client requested Initial Assessment
o Successful (compliant) Result Attribute with an advisory
Remediation Attribute.
6.2 Posture Re-Assessment
Re-assessment(s) of clients can happen anytime after being
admitted to the network after a successful initial NEA
Assessment. These 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.
They may also be periodic (timer-driven) to keep tabs on the
health of the client measurements.
Sangster, et. al. Expires July 2007 [Page 24]
Internet Draft NEA Requirements Jan 2007
Posture P.Broker Transport Transport P.Broker Posture
Collectors Client Client Server Server Validators
| | | | | |
| | initial assessment complete | |
| | |<--------->| |event triggered
| | | | |Posture request
| | | | |<----------|
| | | Posture Req | |
| | Pos Req |<----------|<--------| |
| Pos Req |<--------| | | |
|<--------| | | | |
|Pos Resp | | | | |
|-------->|Pos Resp | | | |
| |-------->| Posture Resp | |
| | |---------->|-------->| Pos Resp |
| | | | |---------->|
| | | | | Decision |
| | | Posture Decision |<----------|
| | Decision|<----------|<--------| |
| Decision|<--------| | | |
|<--------| | | | |
| | | | | |
Figure 3: Illustration of NEA Posture Re-assessment Use case
6.2.1 Triggered by NEA Client
This use case allows for client based software or a User to
determine that a re-assessment of the system is required. There
are a variety of reasons why such a re-assessment 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 network 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
re-Assessment of the firewall compliance. The NEA Server
returns a decision that the firewall must be re-activated to
stay on the network. The NEA Client explains the decision to
the User and how to re-activate the firewall. The HR person
re-starts the firewall and initiates a request to re-join the
network.
Sangster, et. al. Expires July 2007 [Page 25]
Internet Draft NEA Requirements Jan 2007
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 which typically might act
as a Posture Collector triggers the Posture Broker Client
to initiate a Posture Re-assessment. This PB Message
contains a PA Message with the appropriate Posture
Attribute indicating the disabled desktop firewall.
2. The Posture Broker Client sends the PB Message to the
Posture Broker Server. The Posture Broker Client will
create a new session for the assessment.
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 Posture Attributes Message to the Firewall
Posture Validator responsible for handling Firewall
related Posture Attribute(s).
5. The Firewall Posture Validator processes the new value(s)
of the Posture Attribute(s) and determines that the
Endpoint is no longer compliant.
6. The Posture Validator generates a PA Message that includes
a Result Attribute with the Posture Assessment Decision
set to non-compliant and Remediation Attributes indicating
how to re-activate the firewall.
7. The Posture Validator communicates the PA Message with the
Posture Assessment Result to the Posture Broker Server and
instructs it to respond back to the NEA Client.
8. The Posture Broker Server generates a PB Message with the
Global Posture Assessment Decision and 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 Result Attribute
received from the NEA Server and displays non-compliance
messages to the end user.
11. The Posture Broker Client forwards the PA Message to the
Firewall Posture Collector; the Posture Collector guides the
end user with instructions to be compliant which includes
enabling the Desktop Firewall.
12. The end User will be prompted to initiate a Re-assessment
after completing the Remediation.
13. Upon completion of the remediation, the NEA Client re-
initiates a request for re-assessment 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 successful Posture Broker Server generates a PB Message
with a Global Posture Assessment of compliant and returns this
to the NEA Client.
Sangster, et. al. Expires July 2007 [Page 26]
Internet Draft NEA Requirements Jan 2007
6.2.1.3 Impact on Requirements
o Voluntary, client (software) initiated Posture evaluation
request
o NEA Server requests specific firewall-oriented Posture
Attributes
o NEA Client (firewall Posture Collector) interact with user
to fix problem
6.2.2 Triggered by NEA Server
In many cases, especially for re-assessment, the server may
initiate specific or complete re-assessment of one or more client
Endpoints triggered by:
o Time (periodic)
o Event occurrence
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 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 it to be installed by
5PM. This policy change causes the NEA Server to request a re-
assessment to determine what Endpoints are impacted and
lacking the patches. The marketing employee’s laptop is re-
assessed and determined to need the patches. A remediation
advisory is sent and presented to the employee how to obtain
the patch and that it must be installed by 5PM. The marketing
employee immediately downloads and installs the patch and
obtains an assertion that the patches are now installed.
At 5PM the enterprise performs another re-assessment of all
impacted Endpoints to determine if they are now in compliance.
The marketing employee’s laptop is re-assessed and presents
the assertion that it has the patches installed and thus is
allowed to remain on the network.
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 OS Patch policy
for indicating that recent patches are required on all
Sangster, et. al. Expires July 2007 [Page 27]
Internet Draft NEA Requirements Jan 2007
Endpoints by 5PM to prevent serious vulnerabilities.
3. The NEA Server’s OS Patch Posture Validator become aware
of this policy change and creates a PA Message containing
a Request Attributes for information about OS patches in
use and triggers the Posture Broker Server to initiate a
Posture Re-Assessment of all Endpoints connected to the
network.
4. The Posture Broker creates a PB message that includes the
PA Message that contains the set of Request Attribute(s)
that are related to OS patch versions.
5. The Posture Broker Server establishes a session with each
available NEA Client. The rest of the flow focuses on the
exchanges between the NEA Server and one NEA Client; the
NEA Server will engage in such a Message Dialog with each
available NEA Client.
6. The Posture Broker Server sends the PB Message to the
Posture Broker Client.
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 appropriate Posture
Collector responsible for handling OS Patch Request
Attribute(s).
9. The OS Patch Posture Collector determines the OS patches
present on the Endpoint and if authorized by its
disclosure policy accumulates the value(s) for each
Posture Attribute requested by the Posture Validator.
10. The OS Patch Posture Collector constructs a PA Message and
includes the authorized Posture Attributes accumulated
about the OS patches.
11. The Posture Collector instructs the Posture Broker Client
to respond back to the NEA Server with the PA Message.
12. The Posture Broker Client sends a PB Message that includes
the OS Patch PA Message.
13. The Posture Transport Client transports the PB Message to
the Posture Transport Server where it is passed to the
Posture Broker Server.
14. The Posture Broker Server receives the PB Message and delivers
the PA Message to the OS Patch Posture Validator.
15. The OS Patch Posture Validator extracts the Posture
Attribute(s) 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.
16. The Posture Validator generates a PA Message that includes
a Result Attribute with the Posture Assessment Decision
set to non-compliant and appropriate Remediation
Attributes to enable the Endpoint to download the required
OS patches.
Sangster, et. al. Expires July 2007 [Page 28]
Internet Draft NEA Requirements Jan 2007
17. The Posture Validator communicates the Posture Assessment
Result to the Posture Broker Server and instructs the
Posture Broker to respond back to the NEA Client with the
Posture Attribute Message.
18. The Posture Broker Server generates a Global Posture
Assessment Decision and sends a PB Message with the Result
Attribute and Posture Attribute Message.
19. The Posture Transport Server transports the PB Message to
the Posture Transport Client where it is passed to the
Posture Broker Client.
20. The Posture Broker Client processes the Result Attribute
received from the NEA Server and displays the non-compliance
messages to the User.
21. The Posture Broker Client forwards the PA Message to the OS
Patch Posture Collector; the Posture Collector guides the User
with instructions on how to become compliant that includes
downloading the appropriate OS patches to prevent the
vulnerability.
22. The marketing employee installs the required patches and how
is in compliance.
23. The NEA Client triggers a re-assessment of the OS Patches
which causes a repeat of many of the steps above. This time
step 15 determines the marketing employee’s laptop is
compliant and returns re-usable (signed and dated) Assertion
Attributes in the PA Message instead of Remediation Attributes
as before.
24. This time when the OS Patch Posture Collector receives the PA
Message that contains Assertion Attributes which is caches for
future use.
25. Later at 5PM, the NEA Server triggers a Re-assessment to
determine compliance to the patch advisory. When the OS Patch
Posture Collector receives the Request Attributes (like in
step 9-10 above) it will return Assertion Attributes (instead
of Posture Attributes) to indicate that the patches have been
installed instead of engaging in the entire assessment
process.
26. When the OS Patch Posture Validator receives the PA Message
containing the Assertion Attributes it is able to determine
that they are authentic and returns a Posture Assessment
Decision of compliant thus allowing the laptop to remain on
the network.
6.2.2.3 Impact on Requirements
o Server initiated re-assessment required due to urgent patch
availability
o NEA Client submits Assertion Attributes instead of Posture
that patch is installed
o NEA Server capable of recognizing Assertion Attributes are
sufficient instead of Posture Attributes
Sangster, et. al. Expires July 2007 [Page 29]
Internet Draft NEA Requirements Jan 2007
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 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 may 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 which are sufficient.
7.1 Common Protocol Requirements
The following are the common requirements that apply to the
PA, PB and PT protocols in NEA conceptual architecture:
C-1 NEA protocols MUST be capable of performing a multiple
Message Dialog between the NEA Client and NEA Server.
This allows for Assessment models that require more than
one round trip to complete the Assessment. This also
allows for updates to already reported Posture
information. These updates allow for detection of recent
changes in the client state (e.g. possibly due to a
remediation.)
C-2 NEA protocols MUST allow the NEA Server to initiate
requests for Posture information prior to network access
and at any time after the Endpoint has established
network connectivity.
C-3 NEA protocols MUST provide a way for both the NEA Client
and the NEA Server to initiate a Posture re-assessment
request as needed.
C-4 NEA protocols MUST provide protection against active and
passive attacks by intermediaries including protection
to prevent replay based attacks.
C-5 The PA and PB protocols defined by NEA MUST be agnostic
of the transport i.e. 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, PANA, and IKE/IPsec.)
Sangster, et. al. Expires July 2007 [Page 30]
Internet Draft NEA Requirements Jan 2007
C-6 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-7 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-8 The protocols MUST support efficient transport of a
large number of Attributes Messages between the NEA
Client and the NEA Server.
C-9 The protocols MUST support deployments that have large
numbers of compliance policies.
C-10 The protocols MUST allow for Assessment modes that can
reduce the amount information to be exchanged between
the NEA Client and Server to complete an assessment.
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 an NEA Server. The PA protocol
carries collections of core attributes and vendor-defined
attributes. The PA protocol itself is carried inside the PB
protocol.
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 transport of the required
(core) Attributes defined in the data model.
PA-2 The PA protocol MUST support the transport of vendor-
defined Attributes.
PA-3 The PA protocol MUST enable a Posture Validator to request
Posture, Compliance Claims, and Assertion Attributes about
particular Components on the NEA Client system from its
peer Posture Collector.
Sangster, et. al. Expires July 2007 [Page 31]
Internet Draft NEA Requirements Jan 2007
PA-4 The PA protocol MUST enable a Posture Validator to request
Posture, Compliance Claims, and Assertion Attributes from
its peer Posture Collector on more than one occasion using
an existing or new Session. This enables the Posture
Validator to reassess the Posture of a particular Component
or to request information about additional Component.
PA-5 The PA protocol MUST be capable of returning Results and
Remediation Attributes from the Posture Validator. This
enables the Posture Collector to learn the specific reason
for a failed Assessment and to aid in remediation and
notification of the system owner.
PA-6 The PA protocol SHOULD support expression of core
Attributes to describe remediation state of Components, for
example, last update time or remediation server used. These
Attributes are used after remediation so that a Posture
Validator can synchronize with a Posture Collector and
continue remediation.
PA-7 The PA protocol MUST support authentication, integrity, and
confidentiality of Attributes, results, and remediation
instructions sent between a Posture Collector and Posture
Validator. This enables end-to-end security across an NEA
deployment that might involve traversal of several systems.
PA-8 The PA protocol MUST be capable of carrying attributes that
contain binary data including encrypted content.
PA-9 String Attributes MUST support being encoded with an
encoding standard that supports internationalization.
7.3 Posture Broker (PB) Protocol Requirements
The PB protocol supports multiplexing of Posture Attribute
Messages (based on PA protocol) from multiple Posture Collectors
associated with a NEA Client and transmitting them to an NEA
Server, where they can be de-multiplexed to potentially multiple
corresponding Posture Validators.
The PB protocol carries the global 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. The PB protocol also aggregates and transports advisories
and notifications such as remediation instructions and 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 the Result
Attributes and, if appropriate, the Remediation Attributes
from the Server Broker to the Client Broker.
Sangster, et. al. Expires July 2007 [Page 32]
Internet Draft NEA Requirements Jan 2007
PB-2 The PB protocol MUST carry identifiers that are used by the
Posture Brokers to route (deliver) Messages between peer
Posture Collectors and Posture Validators. Such Message
routing should facilitate dynamic (de)registration of
Posture Collectors and Validators to the NEA service. 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-3 The PB protocol MUST support creation and management of a
Session that can carry a Message Dialog between one or more
Posture Collectors and Posture Validators. This allows
each party to send multiple Messages before the dialog is
complete.
PB-4 The PB protocol SHOULD support authentication, integrity
and confidentiality protection for the Attribute Messages
it carries between an NEA Client and Server. This provides
security protection for a Message Dialog of the groupings
of Attribute Messages exchanged between the NEA Client and
Server. Such protection is orthogonal to PA protections
(which are end to end) and allow for simpler Posture
Collector and Validators be implemented, and for
consolidation of cryptographic operations possibly
improving scalability and manageability.
PB-5 The PB protocol MUST support grouping of Attribute Messages
to optimize transport of Messages and minimize round trips.
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, TLS, or IKE.
This section defines the requirements that candidate PT protocols
must be capable of supporting.
PT-1 The PT protocol SHOULD incur low overhead to accommodate us
on low bandwidth links
PT-2 The PT protocol SHOULD be capable of supporting a half-
duplex communication environment.
PT-3 The PT protocol MUST NOT attempt to interpret the contents
of PB Messages being transported, i.e., the data it is
carrying must be opaque to it.
Sangster, et. al. Expires July 2007 [Page 33]
Internet Draft NEA Requirements Jan 2007
PT-4 The PT protocol MUST be capable of protecting the integrity
and confidentiality of the PB Messages between the Posture
Transport Client and the Posture Transport Server. This
includes protection against replay and reflection.
PT-5 The PT protocol MUST provide reliable delivery for the PB
protocol. This includes the ability to perform
fragmentation, reassembly, and detect duplicates and
reorder to provide in-sequence delivery, as required.
PT-6 The PT protocol MUST be capable of supporting mutual
authentication between the Posture Transport Client and the
Posture Transport Server. This MAY occur by leveraging by-
products (e.g., keys) supplied by the PB protocol
authentication.
PT-7 The PT protocol MUST support establishing a restricted
Session between the Posture Transport client and the
Posture Transport server prior to the NEA Client being
granted unrestricted network access.
PT-8 The PT protocol MUST allow either the Posture Transport
Client or the Posture Transport Server to initiate a
restricted session for use by NEA when both parties have
necessary network addresses established.
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
reference model’s components.
8.1 Trust
Network Endpoint Assessment is oriented towards protecting the
assets and other Endpoints on the network from damage caused by
the presence of risky Endpoints potentially harboring malware.
Therefore, there is an implied distrusting of an Endpoints until
there is reason to believe (or proof) that they can be trusted to
not infect/attack network resources or other Endpoints. On the
network provider side, the NEA Client frequently is expected to
trust the network infrastructure systems not to misuse any
disclosed Posture information (see section 9) and any remediation
instructions necessary to join the network. The NEA Client
normally needs to trust that the NEA Server will only request
information required to determine whether the Endpoint is safe to
access the network assets.
Sangster, et. al. Expires July 2007 [Page 34]
Internet Draft NEA Requirements Jan 2007
In between the NEA Client and Server 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 of these parties is deployment specific.
The NEA Reference Model 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.
8.1.1 Client Components
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) and is not
specifically addressed by the model. However if such mechanisms
do come into existence, 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 Components from attack and assure the ability of Posture
Collectors to view the actual Posture.
Besides having to trust the integrity of the NEA Components and
their ability to properly 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.
However, one approach assumes more trust in the Endpoint. This
approach allows for the NEA Client to receive compliance policies
in Policy Attributes and perform the comparison of the current
Posture to the policies and make a claim of compliance in
Compliance Claim Attributes to the NEA Server instead of
providing the Posture Attributes themselves. In this case, we
must trust the Endpoint’s policy storage, comparison 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 it has been
specifically authorized by the User or Owner policy. The NEA
Reference Model assumes all the NEA Client components are local
to the Endpoint and communicate over local API or program calls.
Unsolicited communications originating from the network should be
inspected by normal security protective mechanisms (e.g.
firewalls, security protocols, IDS/IPS, etc.) Communications
associated with the NEA Assessment or re-assessment requires some
level of trust particularly when initiated by the NEA Server (re-
assessment.) 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. Expires July 2007 [Page 35]
Internet Draft NEA Requirements Jan 2007
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 may have the opportunity to observe and change the Message
Dialogs.
The intermediary devices may fall into a few major categories
which 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, or alike.) For these
devices we trust them not to drop the Messages or actively 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 by the NEA Server. 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’s 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 [RADIUS] session.)
Fourth, many networks include infrastructure such as IDS/IPS
devices which monitor and take corrective action when suspicious
behavior is observed on the network. These devices may have a
relationship with the NEA Server which 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 which 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’s desired that
NEA deployers not be forced to trust them for NEA to reliably
operate. Therefore, it is important 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. Expires July 2007 [Page 36]
Internet Draft NEA Requirements Jan 2007
8.1.3 Server Components
The NEA Server components including systems providing (remote)
Posture Validation are generally trusted to enforce the specified
Assessment policies and are protected from compromise. It’s
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 we need to trust the NEA Server operation to some degree,
rigorous security architecture, analysis, monitoring and review
should assure their network footprint and internal workings are
protected from attack. The network footprint would include
communications over the network which 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 Component communications, Component inner workings
or policy stores particularly those that would change the
resulting decisions or enforcements. The NEA Server needs to
trust the underlying carrier 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 combines aspects of both areas, where
each of the NEA Server Components reside on different systems.
This might occur when a Posture Validator (or a remote backend
server used by a local Posture Validator) exists of another
system from the Posture Broker Server. Similarly, the Posture
Broker Server might exist on a separate system from the Posture
Transport Server. In these situations, the network
communications require strong protections to assure network based
attacks can not alter the PB Session and PA Message Dialogs
particularly by alteration or spoofing of the communications.
8.2 Overlapping Protections
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 protections. These 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
Sangster, et. al. Expires July 2007 [Page 37]
Internet Draft NEA Requirements Jan 2007
also selectively encrypt some set of Posture Attributes to
achieve end to end confidentiality to its peer Posture Validator.
In particular, this might be desired when the Posture Validator
is not co-located with the PT Server so the information will
traverse additional network segments after the PT protections
have been enforced.
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 enforcing 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.
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 sit 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 themselves as an
active participant (proxy) within the communications without
Sangster, et. al. Expires July 2007 [Page 38]
Internet Draft NEA Requirements Jan 2007
detection (assuming attacker lacks credentials convincing either
party it is legitimate.) Re-usable 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 encrypted
communications (in conjunction with the above authentication)
might prevent a passive MITM from observing the Message Dialog
and keeping a record of the conformant Posture values for future
use.
8.3.2 Message Modification
Without Message integrity protection, an attacker capable of
interception of 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
malware infested machine to be admitted by changing the sent
Posture Attributes to reflect a compliant values, thus hiding the
malware from the Posture Validator.
In order to protect against such attacks, the PT includes a
requirement for strong integrity protection (e.g. including a
protected hash like an HMAC [HMAC] of the Message) so this change
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
existed on a 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 client for later re-use 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 can not obtain
the information in the first place.
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
Sangster, et. al. Expires July 2007 [Page 39]
Internet Draft NEA Requirements Jan 2007
the encrypted Message if there is no strong link to the
originating party or 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’s not
practical to try to define the all of the potential exposures
present within the NEA protocols, so such an analysis should be
included in the Security Considerations sections of the
technology selection specifications.
However, it’s 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 underlying carrier protocols would have
some amount of DoS resilience and that the NEA 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 carrier protocols that
enable an early authentication of the requesting Endpoint as one
technique for filtering out attacks. The PT protocol also
requires support of a mutual authentication that can be used in
addition to (or in lieu of) the carrier authentication to limit
the window of unauthenticated attack against the Posture
assessment.
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 carrier and/or 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.
Sangster, et. al. Expires July 2007 [Page 40]
Internet Draft NEA Requirements Jan 2007
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.
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 specify protocols
targeting the use cases where the Endpoints and network are
owned by the same party or a clear expectation of
disclosure/compliance has been established 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 their
use should they 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’s 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.
Sangster, et. al. Expires July 2007 [Page 41]
Internet Draft NEA Requirements Jan 2007
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.
Implementations are encouraged to offer an opt-in policy for
use of NEA 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 are allowed to be
disclosed. Requests for Attributes that are explicitly not
allowed 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 they are willing to
share his information as well in order to gain access.
Product might consider prompting the User for authorization
with a specific description of the Posture being requested
prior to sending it to the NEA Server.
It’s envisioned that the Owner of the Endpoint is able to
specify disclosure policies that may override or influence the
User’s policies of 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 to whether to use the Endpoint in
those circumstances.
In such a system, it is important that the User’s policy
authoring interface be 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, it’s
possible that a ‘that which is not explicitly authorized for
disclosure is not allowed’ semantic 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/protected,
o What local privacy policies are applicable.
Sangster, et. al. Expires July 2007 [Page 42]
Internet Draft NEA Requirements Jan 2007
This information will empower subscribing Users to decide
whether the disclosure of this information is acceptable
considering local laws and customs.
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 benefits and issues and these descriptions are
provided to seed discussion as to whether each is feasible and
whether a preferred approach will emerge potentially impacting
the protocols and general privacy of NEA.
These models assume a NEA Client resident on the Endpoint and
thus able to access privacy sensitive information. If a
deployer wishes to support Endpoint Assessment without a NEA
Client (e.g. basing Posture on network observed behaviors)
this could improve the privacy but may limit what information
is ascertainable thus impacting flexibility of NEA Server
policy.
The first model is very simple 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 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
Attribute 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
system.
Sangster, et. al. Expires July 2007 [Page 43]
Internet Draft NEA Requirements Jan 2007
The third model avoids the need for pre-provisioning of
disclosure policy by allowing the NEA Server to specifically
request what Attributes are required. This is somewhat
analogous to the policy being provision 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 a Linux system, ask for a different/smaller set of
Attributes specific to Linux then it would if the client was a
Windows system. It’s envisioned that this 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 set a privacy filter policy
enforced by the NEA Client to prevent the disclosure of
Attributes felt to be personal in nature or not relevant to
the 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.)
10. References
10.1 Normative References
[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson
J., and H. Levkowetz, ‘‘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., Atkinson, R., ’’Security Architecture
for the Internet Protocol’’, RFC 2401, November
1998.
[KEYWORDS] S. Bradner, "Keywords for use in RFCs to
Indicate Requirement Levels", RFC2119 (BCP),
IETF, March 1997.
[RADIUS] Rigney, C., Willens, S., Rubens, A., and
Simpson, W., ‘‘Remote Authentication Dial In
User Service (RADIUS)’’, RFC 2865, June 2000.
[TLS] Dierks, T., Rescorla, E., ‘‘The Transport Layer
Security (TLS) Protocol Version 1.1’’, RFC
4346, April 2006.
Sangster, et. al. Expires July 2007 [Page 44]
Internet Draft NEA Requirements Jan 2007
10.2 Informative References
[CNAC] Cisco, Cisco’s Network Admission Control Mail
Web Site, http://www.cisco.com/go/nac
[NAP] Microsoft, NAP Main Web Site,
http://www.microsoft.com/nap
[TNC] Trusted Computing Group, Trusted Network
Connect Mail Web Site,
https://www.trustedcomputinggroup.org/groups/n
etwork/
Acknowledgments
The authors of this draft would like to acknowledge the NEA
working group members who have contributed to previous
requirements and problem statement drafts that influenced the
direction of this specification: Kevin_Amorin, Diana Arroyo, Uri
Blumenthal, Steve Hanna, Thomas Hardjono, Ravi Sahita, Mauricio
Sanchez, Jeff Six, Susan Thompson, John Vollbrecht, Hao Zhou.
Authors’ Addresses
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
mmani@avaya.com
Kaushik Narayan
Cisco Systems Inc.
10 West Tasman Drive
San Jose, CA 95134
Phone: +1 408 526-8168
kaushik@cisco.com
Paul Sangster
Symantec Corporation
6825 Citrine Dr
Carlsbad, CA 92009 USA
Email: Paul_Sangster@symantec.com
Sangster, et. al. Expires July 2007 [Page 45]
Internet Draft NEA Requirements Jan 2007
Joseph Tardo
Nevis Networks
500 N. Bernardo Ave.
Mountain View, CA 94043 USA
Email: joseph.tardo@nevisnetworks.com
Copyright Statement
Copyright (C) The Internet Society (2007). 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 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.
Sangster, et. al. Expires July 2007 [Page 46]
| PAFTECH AB 2003-2026 | 2026-04-24 04:31:33 |