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 (iesg@ietf.org)
by October 23rd.
+++
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. 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
_______________________________________________
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce
