* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Nea Status Pages

Network Endpoint Assessment (Concluded WG)
Sec Area: Roman Danyliw, Benjamin Kaduk | 2006-Oct-31 — 2014-May-09 
Chairs
 
 


2014-03-05 charter

Network Endpoint Assessment (nea)
---------------------------------

 Charter

 Current Status: Active

 Chairs:
     Stephen R. Hanna <shanna@juniper.net>
     Dr. Susan Thomson <sethomso@cisco.com>

 Security Area Directors:
     Stephen Farrell <stephen.farrell@cs.tcd.ie>
     Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>

 Security Area Advisor:
     Stephen Farrell <stephen.farrell@cs.tcd.ie>

 Mailing Lists:
     General Discussion: nea@ietf.org
     To Subscribe:       http://www.ietf.org/mailman/listinfo/nea
     Archive:            http://www.ietf.org/mail-archive/web/nea

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 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. An endpoint supporting NEA protocols can be queried for
     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"). Specifying mechanisms for providing restricted
     access is outside the scope of the NEA WG.

     Since NEA involves many different components from different vendors,
     interoperability is important. The NEA working group will
     develop standard protocols at the following three  layers in the
    architecture:
     the Posture Attribute protocol (PA),  the Posture Broker protocol
     (PB), and the Posture Transport protocol (PT). PA and PB will be
    designed to
     support a variety of PT protocols. Together,  PA, PB and the mandatory to
     implement PT 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
     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).

     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 that are expected to address many common
     posture policies. Vendor-specific attributes will also be supported;
     vendor-specific attributes will be identified by a private enterprise
     number and a vendor assigned value. Vendors are strongly encouraged to
     document vendor-specific attributes in an RFC. The NEA WG will
     investigate the use of a standard syntax for all attributes.

     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
    expectation
     is that the PT protocol is a shim protocol that defines an
    encapsulation of PB
     within an existing standard transport protocol. Existing standard transport
     protocols will be leveraged to the extent possible. The NEA WG may specify
     more than one PT to meet the requirements of different deployment
    scenarios.
     The NEA WG will specify at least one mandatory to implement PT protocol.
     PT protocol specifications must describe any limitations
     that they impose on PB and PA (e.g. half duplex).

     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 is applicable to computing
     enterprise environments, where endpoints accessing the enterprise's
     network are owned and/or expected to conform to the policies set forth
     by the organization that owns and operates the network. All other
     cases are outside the scope of the NEA charter, since we do not know
     that NEA would be useful in such cases. 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.




Goals and Milestones:
  Done     - At IETF 67, discuss issues with NEA Requirements I-D
  Done     - Submit first draft of NEA Requirements I-D
  Done     - At IETF 68, resolve any open issues with requirements I-D
  Done     - Discuss NEA Requirements I-D
  Done     - WGLC on NEA requirements I-D
  Done     - At IETF 69, resolve any remaining issues raised at Last Call
  Done     - Submit NEA Requirements I-D to the IESG for IETF Last Call as Informational RFC
  Done     - Submit revised NEA requirements I-D
  Done     - Proposals for PA and PB due
  Done     - Review and resolve proposals at IETF 71
  Done     - Post first WG version of PA and PB
  Done     - Post second version of PA and PB
  Done     - Resolve issues at IETF 72
  Done     - Post third version of PA and PB
  Done     - WGLC on PA and PB
  Done     - Resolve WGLC comments at IETF 73
  Done     - Post fourth version of PA and PB
  Done     - IETF LC for PA and PB
  Done     - IESG considers PA and PB for Proposed Standard
  Done     - Call for proposals for the PT protocol(s)
  Done     - Proposals due
  Done     - Review PT protocol proposals
  Done     - Decide how to resolve differences and issues
  Done     - WG Last Call on PT protocols
  Done     - Post second WG version of PT protocols
  Done     - Review and resolve issues
  Done     - Post first WG version of PT protocols
  Done     - Resolve issues from WG Last Call
  Apr 2012 - Post new WG version of PT protocols
  Apr 2012 - Send PT-TLS to IESG for Standards Track
  Apr 2012 - Send PT-EAP to EMU WG for Review
  Apr 2012 - Publish -00 WG I-D on NEA Asokan Attack
  Apr 2012 - WGLC on NEA Asokan Attack
  May 2012 - If Needed, Publish -03 PT-EAP I-D and 2nd WGLC
  May 2012 - Send PT-EAP to IESG for Standards Track
  May 2012 - Publish -01 WG I-D on NEA Asokan Attack
  May 2012 - Send NEA Asokan Attack Analysis to IESG for Informational


All charter page changes, including changes to draft-list, rfc-list and milestones:



Generated from PyHt script /wg/nea/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -