FYI,
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.
Cheers,
- 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 sharplabs.com
-----Original Message-----
From: owner-netconf at ops.ietf.org [mailto:owner-netconf at ops.ietf.org]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?
Randy
> From: "IESG Secretary" <iesg-secretary at ietf.org>
> To: <ietf-announce at ietf.org>
> Cc: <nea at ietf.org>
> 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 ietf.org)
> by October 9.
>> +++
>> Network Endpoint Assessment (nea)
> ======================================
>> Current Status: Proposed Working Group
>> Chair(s):
> TBD
>> Security Area Director(s):
> Russ Housley <housley at vigilsec.com>
> Sam Hartman <hartmans-ietf at mit.edu>
>> Security Area Advisor:
> Russ Housley <housley at vigilsec.com>
>> Mailing List: nea at ietf.org>> 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 ietf.org>https://www1.ietf.org/mailman/listinfo/ietf-announce
--
to unsubscribe send a message to netconf-request at ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>
--
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