Subject: [dns-dir] FW: WG Review: Recharter of Network Endpoint Assessment (nea)

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 15 Sep 2009 20:28:24 +0200

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
IESG Secretary
Sent: Tuesday, September 15, 2009 9:00 PM
To: [email-masked]
Subject: WG Review: Recharter of Network Endpoint Assessment (nea) 

A modified charter has been submitted for the Network Endpoint
Assessment
(nea) working group in the Security Area of the IETF.  The IESG has not
made any determination as yet.  The modified charter is provided below
for informational purposes only.  Please send your comments to the IESG
mailing list ([email-masked]) by Tuesday, September 22, 2009.

Network Endpoint Assessment (nea)
------------------------------------------------------------
Last Modified: 2009-08-24

Additional information is available at tools.ietf.org/wg/nea
Chair(s):

    * Stephen Hanna ([email-masked])
    * Susan Thomson ([email-masked])

Security Area Director(s):

    * Tim Polk ([email-masked])
    * Pasi Eronen ([email-masked])

Security Area Advisor:

    * Tim Polk ([email-masked])

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: http://www.ietf.org/mailman/listinfo/nea
Archive: http://www.ietf.org/mail-archive/web/nea

Description of Working Group:

Network Endpoint Assessment (NEA) architectures have been implemented in
the industry to assess the "posture" of endpoint devices for the
purposes of monitoring compliance to an organization's posture policy
and optionally restricting access until the endpoint has been updated to
satisfy the posture requirements. An endpoint that does not comply with
posture policy may be vulnerable to a number of known threats that may
exist on the network. The intent of NEA is to facilitate corrective
actions to address these known vulnerabilities before a host is exposed
to potential attack. Note that an endpoint that is deemed compliant may
still be vulnerable to threats that may exist on the network. The
network may thus continue to be exposed to such threats as well as the
range of other threats not addressed by maintaining endpoint compliance.

Posture refers to the hardware or software configuration of an endpoint
as it pertains to an organization's security policy. Posture may include
knowledge that software installed to protect the machine (e.g.
patch management software, anti-virus software, host firewall software,
host intrusion protection software or any custom software) is enabled
and up-to-date. An endpoint supporting NEA protocols can be queried for
posture information.

An organization may make a range of policy decisions based on the
posture of an endpoint. NEA is not intended to be prescriptive in this
regard. Supported deployment scenarios will include, but are not limited
to, providing normal access regardless of compliance result along with
any recommendations for remediation ("advisory mode"), as well as
providing restricted access sufficient for remediation purposes and any
essential services until an endpoint is in compliance ("mandatory
mode"). Specifying mechanisms for providing restricted access is outside
the scope of the NEA WG.

Since NEA involves many different components from different vendors,
interoperability is important. The NEA working group will develop
standard protocols at the following three  layers in the
architecture: the Posture Attribute protocol (PA),  the Posture Broker
protocol (PB), and the Posture Transport protocol (PT). PA and PB will
be  designed to support a variety of PT protocols. Together,  PA, PB and
the mandatory to implement PT protocols will allow interoperability
between an NEA Client from one vendor and an NEA Server from another.

Since there are already several non-standard protocols at these layers,
the NEA working group will consider these existing protocols as
candidates for the standard protocols. A requirements document will be
written and used as a basis for evaluating the candidate protocols. The
working group may decide to standardize one of the candidate protocols,
use one of them as a basis for a new or revised protocol, or decide that
a new protocol is needed.

The NEA Requirements document will include a problem statement,
definition of terms, requirements for the PA and PB protocols, and an
overall security analysis. It will also include generic requirements for
the protocol transporting PA, PB: the Posture Transport protocol (PT).

The PA (Posture Attribute) protocol consists of posture attributes that
are carried between a particular Posture Collector in a NEA client and a
particular Posture Validator in a NEA Server. The PA protocol is carried
inside the PB protocol. A base set of standard posture attributes will
be specified that are expected to address many common posture policies.
Vendor-specific attributes will also be supported; vendor-specific
attributes will be identified by a private enterprise number and a
vendor assigned value. Vendors are strongly encouraged to document
vendor-specific attributes in an RFC. The NEA WG will investigate the
use of a standard syntax for all attributes.

The PB (Posture Broker) protocol aggregates posture attributes from one
or more Posture Collectors in an NEA client and sends them to the NEA
server for assessment by one or more Posture Validators.

The PT (Posture Transport) protocol carries the PB protocol. The
expectation is that the PT protocol is a shim protocol that defines an
encapsulation of PB within an existing standard transport protocol. 
Existing standard transport protocols will be leveraged to the extent
possible. The NEA WG may specify more than one PT to meet the
requirements of different deployment scenarios. The NEA WG will specify
at least one mandatory to implement PT protocol. PT protocol
specifications must describe any limitations that they impose on PB and
PA (e.g. half duplex).

One commonly discussed issue with NEA systems is how to handle
compromised endpoints, whose reports of their own posture may not be
accurate. Detecting or handling such endpoints is out of scope of the
NEA WG. Work on PA will focus on attributes useful for assessing posture
of those endpoints reporting accurate information. However, the
protocols developed by the NEA WG must be designed to accommodate
emerging technologies for identifying and dealing with lying endpoints.

Note that NEA is not chartered to develop standard protocols for
remediation. NEA is intended to be used with new or existing tools that
can be used in the absence of NEA. NEA is applicable to computing
enterprise environments, where endpoints accessing the enterprise's
network are owned and/or expected to conform to the policies set forth
by the organization that owns and operates the network. All other cases
are outside the scope of the NEA charter, since we do not know that NEA
would be useful in such cases. NEA applicability and security
considerations will be described in the appropriate NEA documents.

Further work in the NEA WG will be considered via the rechartering
process after the completion of these milestones.

Milestones

Done      At IETF 67, discuss issues with NEA Requirements I-D
Done      Submit first draft of NEA Requirements I-D
Done      At IETF 68, resolve any open issues with requirements I-D
Done      Submit revised NEA requirements I-D
Done      Discuss NEA Requirements I-D
Done      Submit revised NEA requirements I-D
Done      WGLC on NEA requirements I-D
Done      At IETF 69, resolve any remaining issues raised at Last Call
Done      Submit revised NEA requirements I-D
Done      Submit NEA Requirements I-D to the IESG for IETF Last Call as 
           Informational RFC
Done      Submit revised NEA requirements I-D
Done      Proposals for PA and PB due
Done      Review and resolve proposals at IETF 71
Done      Post first WG version of PA and PB
Done      Post second version of PA and PB
Done      Resolve issues at IETF 72
Done      Post third version of PA and PB
Done      WGLC on PA and PB
Done      Resolve WGLC comments at IETF 73
Done      Post fourth version of PA and PB
Done      IETF LC for PA and PB
Done      IESG considers PA and PB for Proposed Standard
Sep 2009  Call for proposals for the PT protocol(s) Oct 2009  Proposals
due Nov 2009  Review PT protocol proposals at IETF 76
          Decide how to resolve differences and issues Dec 2009  Post
first WG version of PT protocol(s) Jan 2010  Review and resolve issues
Feb 2010  Post second WG version of PT protocol(s) Mar 2010  WG Last
Call on PT protocol(s)
          Resolve issues from WG Last Call at IETF 77 Apr 2010  Post
third WG version of PT protocol(s) May 2010  Submit PT protocol(s) to
IESG