[Nea] Revised NEA charter

["Stephen Hanna" <shanna at juniper.net>]

In consultation with Susan and our ADs, I have revised the
proposed NEA WG charter to accomplish these goals:

- Clarify that handling compromised endpoints is thoroughly
  and entirely out of scope for NEA. It is not part of the
  NEA use case, which focusses on uncompromised endpoints.

- Clarify that PT protocols will probably be standardized in
  other WGs since they are not generally specific to NEA

- Clarify that EAP is not at all mandatory

A revised proposed charter is below. Please look it over
and speak up if you have any concerns or comments.

I have also attached a Microsoft Word document that shows
the differences between the last charter rev and this one.

Thanks,

Steve

---------------

Proposed NEA WG Charter
June 21, 2006 Version

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 is not compliant 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 addressing these
known
vulnerabilities before a host is exposed to attack. 

Posture refers to the hardware or software configuration of an
endpoint as it pertains to an organization's security policy. Posture
may include knowledge about the types of hardware and software
installed and their configurations, e.g. OS name and version,
application patch levels, and anti-virus signature file version. On
network access and while connected, an endpoint with an NEA Client can
be queried for posture information which is validated on an NEA Server
as part of network access control.

Since NEA involves many different components from different vendors,
interoperation is highly desirable. Given that well-established
protocols already exist for the lowest layers in the NEA architectures
(such as EAP and RADIUS), 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 components of an NEA Client from one vendor and
components of an NEA Server from another.

Since there are already several existing 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 PA and PB, and an overall security
analysis. It will also include generic requirements for the protocol
transporting PA, PB: the Posture Transport protocol (PT). Specific
requirements for an EAP instantiation of PT will also be identified to
support posture transport in deployments that use EAP. Other
transport-specific requirements serving non-EAP deployments may be
specified in future. Note that PT protocols are likely to be
standardized in other WGs since these protocols are not specific to NEA
and are likely to need to satisfy a broader range of requirements than
just posture transport.

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.

PB, the 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.

PT, the Posture Transport protocol, is a protocol (or stack of
protocols) suitable for carrying the PB protocol at or after
network connection.

The NEA working group will not work on standardizing protocols other
than PA and PB at this time. Further work in the NEA WG or in other WGs
will be considered via the standard rechartering process after the
completion of these milestones.

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.

Milestones:

June 2006:
* Submit first version of NEA Requirements I-D

July 2006:
* Agree on charter and milestones at IETF 66

September 2006:
* WG Last Call on NEA Requirements I-D 

October 2006:
* Deadline for submission of candidate specs for PA and PB
* Submit first version of NEA Evaluation I-D 

November 2006:
* At IETF 67, review NEA Evaluation I-D

December 2006:
* WG Last Call on NEA Evaluation I-D

January 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 Last Call comments on requirements I-D at IETF 69

August 2007:
* Submit PA and PB specs to IESG for publication as Proposed

Attachment: Proposed NEA WG Charter diffs 21Jun06 vs 22May06.doc
Description: Proposed NEA WG Charter diffs 21Jun06 vs 22May06.doc

_______________________________________________
Nea mailing list
Nea at ietf.org
https://www1.ietf.org/mailman/listinfo/nea