Subject: RE: [Nea] Revised draft NEA charter

From: "Blumenthal, Uri" <[email-masked]>
Date: Wed, 17 May 2006 18:05:57 -0400

I don't see PV interface mentioned in the new charter - this omission
should be fixed.

-----Original Message-----
From: Stephen Hanna [mailto:[email-masked]] 
Sent: Wednesday, May 17, 2006 6:00 PM
To: [email-masked]
Subject: [Nea] Revised draft NEA charter

Folks,

Susan and I have revised the draft NEA WG charter to reflect
the consensus of the mailing list as reflected in the NEA Action
Plan agreed to in April.

Please review this draft and send feedback ASAP. Of course,
we can revise the charter up to Montreal but I'd like to get
a solid version by Friday so we can submit our BOF proposal
on Monday as the IESG has requested.

Thanks,

Steve

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

Draft NEA WG Charter
May 17, 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 or enforcing compliance to an organization's
policy for access to the network. 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, 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 between NEA architectures and implementations 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 (known as PA and PB and described
later). When used with the existing 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 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, PB, and an overall security
analysis. It will also include requirements for the protocol
transporting PA, PB (known as PTT and described below).

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.

PTT, the Posture Transport Tunnel protocol is a transport protocol
suitable for carrying the PB protocol at or after network connection.

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:
* Review NEA Evaluation I-D at IETF 67

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

_______________________________________________
Nea mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nea

_______________________________________________
Nea mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nea

---

From: "Stephen Hanna" <[email-masked]>
Date: Thu, 18 May 2006 11:01:05 -0400

Uri,

Thanks for your prompt and clear response.

The action plan agreed to on the mailing list in
April included this item:

 B) Revise proposed NEA charter to focus on
    transport-independent PA and PB and
    requirements for PTT 

Therefore, PV is not considered in scope for NEA,
at least not for now. We could perhaps consider
working on it after we have finished the work items
in our initial charter.

Why was the action plan defined in this way? Because
the feedback from the first BOF was to focus on a
single clear interoperability goal--client-server
interoperability--and to avoid defining transport
protocols since some exist already and in any case
that is the domain of other working groups.

Thanks,

Steve

> From: Blumenthal, Uri [mailto:[email-masked]] 
> Sent: Wednesday, May 17, 2006 6:06 PM
> To: Stephen Hanna; [email-masked]
> Subject: RE: [Nea] Revised draft NEA charter
>