PWG-ANNOUNCE> FW: [2600] FW: WG Review: Network Endpoint Assessment (nea)

PWG-ANNOUNCE> FW: [2600] FW: WG Review: Network Endpoint Assessment (nea)

PWG-ANNOUNCE> FW: [2600] FW: WG Review: Network Endpoint Assessment (nea)

McDonald, Ira imcdonald at
Tue Oct 3 14:17:33 EDT 2006


This is a (proposed) charter for a new IETF WG called
NEA that addresses ONLY the compliance of network
endpoints to organization-specific security policies.

- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald at

-----Original Message-----
From: owner-netconf at [mailto:owner-netconf at]On
Behalf Of Randy Presuhn
Sent: Monday, October 02, 2006 1:05 PM
To: netconf
Subject: Fw: WG Review: Network Endpoint Assessment (nea) 

Hi -

Somehow this sounds vaguely familiar...
Could this be where netconf data models end up actually
being done?


> From: "IESG Secretary" <iesg-secretary at>
> To: <ietf-announce at>
> Cc: <nea at>
> Sent: Monday, October 02, 2006 7:30 AM
> Subject: 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 draft 
> charter was submitted, and is provided for informational purposes only.
> Please send your comments to the IESG mailing list (iesg at 
> by October 9.
> +++
> Network Endpoint Assessment (nea)
> ======================================
> Current Status: Proposed Working Group
> Chair(s): 
> Security Area Director(s):
> Russ Housley <housley at>
> Sam Hartman <hartmans-ietf at>
> Security Area Advisor:
> Russ Housley <housley at>
> Mailing List: nea at
> 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.
> Two deployment scenarios will be supported: advisory mode and mandatory
> mode.
> In advisory mode, an endpoint may be advised of the result of posture 
> assessment
> and any recommended remediation actions, but is provided normal network
> access
> regardless of the result. In mandatory mode, a non-compliant endpoint is
> given
> restricted access to the network sufficient for remediation purposes 
> and any essential
> services or denied access completely.
> 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 in either advisory or mandatory
> modes.
> Since NEA involves many different components from different vendors,
> interoperation is highly desirable. The priority of the NEA working 
> group is to
> standardize protocols at the higher layers in the architectures:
> 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, these new 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 standardization. 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.
> PA, the 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. Certain posture attributes
> will be standardized to ensure interoperability but vendor-specific
> attributes will also be supported. 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 (or stack of protocols) is 
> suitable for carrying
> the PB protocol at the time of network connection, or shortly after.
> 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 standardize protocols for remediation.
> NEA is intended to be used with new or existing tools that can be used in
> the absence of NEA. There is an open issue with respect to NEA
> applicability
> in deployment scenarios where the endpoint is owned by a party that 
> is different
> from the organization providing network access.
> Further work in the NEA WG will be considered via the standard
> rechartering
> process after the completion of these milestones.
> Milestones:
> June 2006:
> * Submit first version of NEA Requirements I-D
> July 2006:
> * Agree on charter and milestones at IETF 66
> 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 2006:
> * Deadline for submission of candidate specs for PA and PB
> * Submit first version of NEA Evaluation I-D
> January 2007:
> * WG Last Call on NEA Evaluation I-D
> February 2007:
> * Submit NEA Requirements I-D and Evaluation I-D to IESG as Info RFC
> * Submit first draft of PA and PB specs for review
> March 2007:
> * Discuss unresolved issues with PA and PB specs at IETF 68
> * Agree on solutions to unresolved issues with PA and PB specs
> April 2007:
> * Submit revised draft of PA and PB specs
> June 2007
> * WG Last Call on PA and PB specs
> July 2007
> * Resolve outstanding WGLC comments on PA and PB specs at IETF 69
> August 2007:
> * Submit PA and PB specs to IESG for publication as Proposed
> September 2007:
> * Decide how to address MTI PT, recharter if needed
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce at

to unsubscribe send a message to netconf-request at with
the word 'unsubscribe' in a single line as the message text body.
archive: <>

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.407 / Virus Database: 268.12.12/461 - Release Date: 10/2/2006

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.407 / Virus Database: 268.12.12/461 - Release Date: 10/2/2006

More information about the Pwg-announce mailing list