Subject: [Nea] FW: Updated charter [UPDATED: WG Review: Network Endpoint Assessment (nea)]

From: "Susan Thomson \(sethomso\)" <[email-masked]>
Date: Tue, 17 Oct 2006 16:22:24 -0400

Folks

This is a charter update based on discussions on mailing list up to
about a week ago.

It includes the following changes:
1. Be explicit about what NEA is not protecting against
2. Modified text on mandatory/advisory mode to make clear subject to
policy and not limited to the deployment modes mentioned 
3. Moved posture definition closer to beginning
4. Revised text on endpoint ownership issue 
5. Modified milestone dates to be more realistic

There is an open issue that is subject of an ongoing thread re scope of
standard attributes. I expect another update based on resolution of that
thread along with a few other clarifications that have been requested.

Thanks
Susan

-----Original Message-----
From: IESG Secretary [mailto:[email-masked]] 
Sent: Tuesday, October 17, 2006 3:50 PM
To: [email-masked]
Cc: [email-masked]
Subject: UPDATED: WG Review: Network Endpoint Assessment (nea) 

A new IETF working group has been proposed in the Security Area.  
The IESG has not made any determination as yet. The following UPDATED 
draft charter was submitted, and is provided for informational purposes
only. Please send your comments to the IESG mailing list ([email-masked])

by October 23rd.

+++

Network Endpoint Assessment (nea)
===================================

Current Status: Proposed Working Group

Chair(s): 
TBD

Security Area Director(s):
Russ Housley <[email-masked]>
Sam Hartman <[email-masked]>

Security Area Advisor:
Russ Housley <[email-masked]>

Mailing List: [email-masked]

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 unknown 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. On network access and while connected, an 
endpoint supporting NEA protocols can be queried for such 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").

Since NEA involves many different components from different vendors, 
interoperability is important. The priority of the NEA working group 
is to develop standard protocols at the higher layers in the 
architecture: the Posture Attribute protocol (PA) and the Posture 
Broker protocol (PB). PA and PB will be designed to support a variety 
of lower layer protocols. When used with standards for lower layers, 
the PA and PB 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 
higher 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). PT protocols may be standardized in other WGs since these 
protocols may not be specific to NEA. The NEA WG will identify one 
mandatory to implement PT protocol to ensure interoperability.

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. Vendor-specific attributes 
will also be supported, but vendor-specific attributes must be 
documented in an RFC.

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 NEA working group will not specify protocols other than PA and PB 
at this time. The expectation is that an existing protocol can be 
used for the PT.

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 can be limited in its 
applicability when the endpoint and the organization providing 
network access are owned by different parties. 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:

October 2006:
* Submit first draft of NEA Requirements I-D

November 2006:
* At IETF 67, discuss issues with NEA Requirements I-D
* Agree on solutions to issues with NEA Requirements I-D

December 2007:
* Submit revised requirements I-D

February 2007:
* WGLC on NEA Requirements I-D
* Deadline for submission of candidate specs for PA and PB

March 2007:
* At IETF 68, resolve outstanding issues with requirements I-D
* Report from NEA protocol evaluation team

April 2007:
* Submit NEA Evaluation I-D

June 2007:
* Submit revised NEA Evaluation I-D
* WGLC on NEA Evaluation I-D

July 2007:
* At IETF 69, review outstanding comments on evaluation I-D

August 2007:
* Submit first draft of PA and PB spec

October 2007:
* Submit revised draft of PA and PB spec
* Decide how to address MTI PT, recharter if needed

December 2007:
* At IETF70, discuss and resolve issues with PA and PB spec

February 2008:
* WGLC on PA and PB spec

_______________________________________________
Nea mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nea