Subject: Fw: WG Review: Network Endpoint Assessment (nea)

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 2 Oct 2006 10:05:24 -0700

Hi -

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

Randy

> From: "IESG Secretary" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> 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 ([email-masked]) 
> by October 9.
> 
> +++
> 
> 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.
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>