[802SEC] FW: [New-work] WG Review: Network Endpoint Assessment (nea)
IEEE 802 WG Chairs,
The following announcement from the IETF may be of interest to your
working groups.
Paul
-----Original Message-----
From: IESG Secretary [mailto:iesg-secretary@ietf.org]
Sent: Monday, October 02, 2006 7:40 AM
To: new-work@ietf.org
Subject: [New-work] 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@ietf.org) by
October 9.
+++
Network Endpoint Assessment (nea)
======================================
Current Status: Proposed Working Group
Chair(s):
TBD
Security Area Director(s):
Russ Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>
Security Area Advisor:
Russ Housley <housley@vigilsec.com>
Mailing List: nea@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
_______________________________________________
New-work mailing list
New-work@ietf.org
https://www1.ietf.org/mailman/listinfo/new-work
----------
This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv.